rfc:spl-improvements

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:spl-improvements [2012/01/08 06:01] – [What is wrong with the SPL?] levimrfc:spl-improvements [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 14: Line 14:
   * **The exceptions are somewhat ambiguous.** Part of this problem is due to the aforementioned documentation issue.  However, the names of some of the exceptions are misleading.   * **The exceptions are somewhat ambiguous.** Part of this problem is due to the aforementioned documentation issue.  However, the names of some of the exceptions are misleading.
     * [[http://php.net/manual/en/class.outofrangeexception.php|OutOfRangeException]]. The name of OutOfRangeException implies that it should be thrown when you give a value that is greater than the maximum or lower than the minimum.  After long consideration, collaboration and examination of its name, documentation and how it is used in the SPL, it seems that it should be used to indicate that you have given an array index of the incorrect type. The general consensus among those who discussed the topic was that this exception is poorly named because it indicates that it should be used when you provide an index that is out of the bounds of the array.  That is what [[http://php.net/manual/en/class.outofboundsexception.php|OutOfBoundsException]] is for.     * [[http://php.net/manual/en/class.outofrangeexception.php|OutOfRangeException]]. The name of OutOfRangeException implies that it should be thrown when you give a value that is greater than the maximum or lower than the minimum.  After long consideration, collaboration and examination of its name, documentation and how it is used in the SPL, it seems that it should be used to indicate that you have given an array index of the incorrect type. The general consensus among those who discussed the topic was that this exception is poorly named because it indicates that it should be used when you provide an index that is out of the bounds of the array.  That is what [[http://php.net/manual/en/class.outofboundsexception.php|OutOfBoundsException]] is for.
-    * [[http://php.net/manual/en/class.domainexception.php|DomainException]]. An exception in the domain is very general.  Couple this with the existence of both OutOfRangeException and InvalidArgumentException and what should DomainException be used for?  It is unclear. DomainException is used only in [[http://php.net/manual/en/splfileobject.setmaxlinelen.php|SplFileObject::setMaxLineLen]] (undocumented, but committed).  Based on its usage, it could be an InvalidArgumentException instead. 
  
-  * **The data-structures violate good programming practices.** +    * [[http://php.net/manual/en/class.domainexception.php|DomainException]]. An exception in the domain is very general Couple this with the existence of both OutOfRangeException and InvalidArgumentException and what should DomainException be used for?  It is unclearDomainException is used only in [[http://php.net/manual/en/splfileobject.setmaxlinelen.php|SplFileObject::setMaxLineLen]] (undocumented, but committed).  Based on its usage, it could be an InvalidArgumentException instead.
-    * [[http://php.net/manual/en/class.splstack.php|SplStack]] and [[http://php.net/manual/en/class.splqueue.php|SplQueue]]. SplStack and SplQueue are fully exposed [[http://php.net/manual/en/class.spldoublylinkedlist.php|SplDoublyLinkedList]]s.  This means you can use an SplStack or SplQueue just as you would use an array. This exposes too much of the implementation to the user and could be a source of bugs.+
  
   * **It lacks a high-level API for a low-level implementation of an array.**  The major goal of the SPL is to solve common problems.  PHP arrays perform multiple duties which works well for most cases.  However, a more narrow  structure is sometimes needed.  SplFixedArray does not quite solve all the needs in this area.  If an application works with a large amount of sequential data but with an unknown size, it is difficult to use SplFixedArray.  Creating a structure that grows according to needs could be very helpful.  Internally it could use SplFixedArray to leverage code reuse, as long as the external API is appropriate.   * **It lacks a high-level API for a low-level implementation of an array.**  The major goal of the SPL is to solve common problems.  PHP arrays perform multiple duties which works well for most cases.  However, a more narrow  structure is sometimes needed.  SplFixedArray does not quite solve all the needs in this area.  If an application works with a large amount of sequential data but with an unknown size, it is difficult to use SplFixedArray.  Creating a structure that grows according to needs could be very helpful.  Internally it could use SplFixedArray to leverage code reuse, as long as the external API is appropriate.
Line 33: Line 31:
     * Accessing an invalid index type should give a message similar to "Invalid index type: expected [valid types]."     * Accessing an invalid index type should give a message similar to "Invalid index type: expected [valid types]."
     * Accessing an out-of-bounds index should give a message similar to "Index '$index' is out-of-bounds."     * Accessing an out-of-bounds index should give a message similar to "Index '$index' is out-of-bounds."
-  * **[[http://php.net/manual/en/class.splobjectstorage.php|SplObjectStorage]] should be split into two structures, a Map and a Set.** SplObjectStorage should then be deprecated and eventually removed.   
  
 The problems that cannot be fixed without breaking backwards compatibility should be carefully discussed and examined.  A plan to correct them should then be created along with a roadmap for when they will be implemented. The problems that cannot be fixed without breaking backwards compatibility should be carefully discussed and examined.  A plan to correct them should then be created along with a roadmap for when they will be implemented.
Line 39: Line 36:
 Some problems that need to be talked about and resolved: Some problems that need to be talked about and resolved:
   * **Exceptions**   * **Exceptions**
-    * Each extension in the SPL should be well defined and documented.  This includes using an example of when the exception could be used. Note: The examples of exceptions being used could be showing an SPL class throwing the given exception.  It would help promote understanding of the SPL structures while clarifying the use of the exception.+    * Each exception in the SPL should be well defined and documented.  This includes using an example of when the exception could be used. Note: The examples of exceptions being used could be showing an SPL class throwing the given exception.  It would help promote understanding of the SPL structures while clarifying the use of the exception.
     * All of the SPL classes should be refactored to align their behavior with the exception clarifications.     * All of the SPL classes should be refactored to align their behavior with the exception clarifications.
-  * **APIs of SplStack and SplQueue.** They should not publicly inherit from SplDoublyLinkedList.  If that causes an issue, then a discussion should be held on other ways to prevent the misuse of SplStack and SplQueue. 
   * **Should the SPL be namespaced?**   * **Should the SPL be namespaced?**
     * If large-scale backwards compatibility is broken, it could be detrimental to do so all at once. However, doing it in pieces is not really reasonable. Namespacing the SPL while keeping the old SPL in place could allow all of the changes to happen without breaking backwards compatibility because the current SPL is not namespaced.     * If large-scale backwards compatibility is broken, it could be detrimental to do so all at once. However, doing it in pieces is not really reasonable. Namespacing the SPL while keeping the old SPL in place could allow all of the changes to happen without breaking backwards compatibility because the current SPL is not namespaced.
     * This could be the beginning of migrating existing PHP extensions and functions to namespaces. If this works well, then there is a viable way to safely break backwards compatibility and could be used in many other areas where breaking backwards compatibility is undesirable.     * This could be the beginning of migrating existing PHP extensions and functions to namespaces. If this works well, then there is a viable way to safely break backwards compatibility and could be used in many other areas where breaking backwards compatibility is undesirable.
rfc/spl-improvements.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1