rfc:internal_constructor_behaviour

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:internal_constructor_behaviour [2015/03/01 18:47] – Corrected typos/grammer danackrfc:internal_constructor_behaviour [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 3: Line 3:
   * Date: 2015-03-01    * Date: 2015-03-01 
   * Author: Dan Ackroyd, Danack@php.net   * Author: Dan Ackroyd, Danack@php.net
-  * Status: Under Discussion+  * Status: Implemented (in PHP 7.0)
   * First Published at: https://wiki.php.net/rfc/internal_constructor_behaviour   * First Published at: https://wiki.php.net/rfc/internal_constructor_behaviour
  
Line 108: Line 108:
  
 Fatal errors should only be used for fatal errors. This RFC proposes that the constructor for PDORow should be changed to throw an appropriate exception rather than giving a fatal error. Fatal errors should only be used for fatal errors. This RFC proposes that the constructor for PDORow should be changed to throw an appropriate exception rather than giving a fatal error.
 +
 +
 +
 +
  
  
Line 151: Line 155:
 ==== To Existing Extensions ==== ==== To Existing Extensions ====
  
-The standard of either returning a usuable instance or throwing an exception in an objects constructor would apply to all extensions that ship with the official PHP release. Other extensions (e.g. those that are hosted on PECL) may wish to follow this standard, but it is not required.+The standard of either returning a usable instance or throwing an exception in an objects constructor would apply to all extensions that ship with the official PHP release. Other extensions (e.g. those that are hosted on PECL) may wish to follow this standard, but it is not required.
  
 ===== Open Issues ===== ===== Open Issues =====
-If anyone feels strongly about splitting the vote into separate parts, please say so. 
  
 +Some of the Intl extension code has always had the behaviour of giving an error notice, and also throwing an exception for the same error. This behaviour should be cleaned up for the release of PHP 7, so that either an error is given, or an exception, but never both.
  
-===== Proposed Voting Choices ===== 
  
-The vote requires 2/3 to pass. +===== Patches and Tests =====
- +
-Should the standard paradigm for constructors for internal objects be to return a usable instance of a class on success, and throw an exception if they encounter an error, and should the code for the classes listed below be modified to follow this standard? +
  
 These classes will be corrected by making the constructor throw an exception rather than return null if the construction of the object fails. These classes will be corrected by making the constructor throw an exception rather than return null if the construction of the object fails.
Line 186: Line 187:
   * Phar   * Phar
   * PharData   * PharData
-* PharFileInfo+  * PharFileInfo
  
  
 The class PDORow will be changed to give an exception if an attempt is made to instantiate it from userland. The class PDORow will be changed to give an exception if an attempt is made to instantiate it from userland.
  
 +The changes have been made in this branch: https://github.com/danack/php-src/tree/InternalClassClean or to view as a PR https://github.com/php/php-src/pull/1178
  
-===== Patches and Tests ===== +The list of exceptions used are: 
-I hope to fix all of these in a branch before opening the vote, so that people can see the details of the changes.+ 
 +Exception - finfo 
 + 
 +IntlException -UConverter, Collator, IntlDateFormatter, MessageFormatter, NumberFormatter3v, ResourceBundle, IntlRuleBasedBreakIterator 
 + 
 +InvalidArgumentException - SplFixedArray 
 + 
 +PDOException - PDO, PDORow 
 + 
 +PharException - Phar, PharData, PharFileInfo 
 +     
 +ReflectionException - ReflectionExtension,  ReflectionFunction, ReflectionMethod, ReflectionParameter, ReflectionProperty, ReflectionZendExtension 
 + 
 + 
 + 
 +===== Voting ===== 
 + 
 + 
 +Should the standard paradigm for constructors for internal objects be to return a usable instance of a class on success, and throw an exception if they encounter an error, and should the code for the classes listed below be modified to follow this standard?  
 + 
 +<doodle title="Constructor behaviour of internal classes" auth="danack" voteType="single" closed="true"> 
 +   * Yes 
 +   * No 
 +</doodle>
  
-At the very least the exception to be used for each class will be determined, and will be an appropriate exception i.e. not \Exception.+Voting will close March 29th 2015 9pm UTC and requires 2/3 in favour to pass.
  
  
 ===== Implementation ===== ===== Implementation =====
 After the project is implemented, this section should contain  After the project is implemented, this section should contain 
-  - the version(s) it was merged to +  - the version(s) it was merged to: 7.0  
-  - a link to the git commit(s) +  - a link to the git commit(s): http://git.php.net/?p=php-src.git;a=commit;h=4796e0242b8cdd2a77b552fcbaa74d70d87f6d0a 
-  - a link to the PHP manual entry for the feature+  - a link to the PHP manual entry for the feature: No new manual entry, the changes are conforming to standard practice.
  
  
rfc/internal_constructor_behaviour.1425235643.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools