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:10] – [Proposal] levimrfc:spl-improvements [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 36: 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.
   * **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

Page Tools