Request for Comments: SPL Improvements

• Version: 1.0
• Date: 2011-12-18
• Author: Levi Morrison levim@php.net
• Status: Work-in-progress

The Standard PHP Library (SPL) is included by default in the latest builds of PHP. It is intended to help solve many common problems. However, it has many problems of its own. This wiki attempts to outline the problems and to propose how they could be fixed.

• The documentation of the SPL is poor in some areas. This makes it difficult to adopt the SPL into projects. Until recently, the SPL data-structures did not document which exceptions they throw and when. That effort is still incomplete as of this writing. A lack of examples is another documentation problem.
• 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.
  • 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 OutOfBoundsException is for.

• 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 SplFileObject::setMaxLineLen (undocumented, but committed). Based on its usage, it could be an InvalidArgumentException instead.

• 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.

All of the problems identified that can be fixed without breaking backwards compatibility should be corrected immediately. This includes but is not limited to:

• Modifying the data-structures to throw more specific exceptions.
  • SplDoublyLinkedList:
    • Should throw an UnderflowException instead of RuntimeException when you call bottom, peek, pop, shift, and top on an empty container.
  • SplFixedArray:
    • Should throw OutOfBoundsException instead of RuntimeException when an index that is a valid type but is out-of-bounds is used in any operation.
    • Should throw OverflowException instead of RuntimeException when you attempt to add a new element to the container.
• Modifying the exceptions message to be more clear.
  • 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.”

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.

Some problems that need to be talked about and resolved:

• Exceptions
  • 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.
• 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.
  • 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.