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 14:44] – 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 12: Line 12:
 i) to make the behaviour of these classes behave more consistently with the behaviour that most people would expect them to have. i) to make the behaviour of these classes behave more consistently with the behaviour that most people would expect them to have.
  
-ii) setting the coding standards that should be followed by internal classes.+ii) setting the behaviour that should be followed by internal classes for their constructors.
  
 If other internal classes that are not listed in this RFC are found to have behaviour that is not consistent with the behaviour listed in this RFC they should be treated as bugs and fixed at the next appropriate release. If other internal classes that are not listed in this RFC are found to have behaviour that is not consistent with the behaviour listed in this RFC they should be treated as bugs and fixed at the next appropriate release.
Line 42: Line 42:
 </code> </code>
  
-This RFC proposes setting a standard that internal classes should either return a valid instance of the class or throw an exception. Also for the classes listed for them to be changed in PHP 7 so that they follow this behaviour.+This RFC proposes setting a standard that internal classes should either return a valid instance of the class or throw an exception. Also for the classes listed to be changed in PHP 7 so that they follow this behaviour.
  
 === Factory methods === === Factory methods ===
  
-The classes IntlDateFormatter, MessageFormatter, NumberFormatter, ResourceBundle and IntlRuleBasedBreakIterator all have a static factory method that can create an instance of the class, as well as the constructor. The factory methods do not currently throw an exception when invalid arguments are passed to it. It is the position of this RFC that it is correct for those factory methods return either null or a valid usable instance of the class.+The classes IntlDateFormatter, MessageFormatter, NumberFormatter, ResourceBundle and IntlRuleBasedBreakIterator all have a static factory method that can create an instance of the class, as well as the constructor. The factory methods do not currently throw an exception when invalid arguments are passed to it. It is the position of this RFC that it is correct for those factory methods to return either null or a valid usable instance of the class.
  
-PHP is a multi-paradigm programming language which support writing code in either procedural or OO style. Having the factory methods behave like this is perfectly consistent with userland code. +PHP is a multi-paradigm programming language which supports writing code in either procedural or OO style. Having the factory methods behave like this is perfectly consistent with userland code. 
  
 <code> <code>
Line 81: Line 81:
 </code> </code>
  
-This RFC proposes that this behaviour should be changed so that the constructor should throw an exception if the class cannot be created in usuable state i.e. convert the current warning to an exception of the appropriate.+This RFC proposes that this behaviour should be changed so that the constructor should throw an exception if the class cannot be created in a usable state i.e. convert the current warning to an appropriate exception.
  
 The list of classes that show this behaviour is: The list of classes that show this behaviour is:
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 to be to either 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 175: Line 176:
  
  
-These classes would be corrected by detecting the invalid data in the constructor and throwing an exception at object construction time, rather giving an error when the created instance is used.+These classes would be corrected by detecting the invalid data in the constructor and throwing an exception at object construction time, rather than giving an error when the created instance is used.
   * UConverter   * UConverter
   * SplFixedArray   * SplFixedArray
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 all of 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.1425221099.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools