rfc:spl-improvements

This is an old revision of the document!


Request for Comments: Spl Improvements

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

Introduction

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.

What is wrong with the Spl?

  • The documentation of the Spl is poor in some areas. This makes it difficult to the Spl adopt 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 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.
  • The data-structures are inconsistent in how they act when in the same situation. Consider the following example where an SplDoublyLinkedList and an SplFixedArray encounter the same problem: an index greater than the size of the container was accessed.
  • <?php
    try {
        $linkedList = new SplDoublyLinkedList();
        $linkedList[1];
    } catch(Exception $error) {
        echo get_class($error) . ': ' . $error->getMessage(). "\n";
    }
    try {
        $fixedArray = new SplFixedArray();
        $fixedArray[1];
    } catch(Exception $error) {
        echo get_class($error) . ': ' . $error->getMessage(). "\n";
    }
    ?>

    The result:

    OutOfRangeException: Offset invalid or out of range
    RuntimeException: Index invalid or out of range

    They do not throw the same exception. Furthermore, SplDoublyLinkedList throws an exception that inherits from LogicException when it is not a logical exception but a runtime one.

  • The data-structures do not throw the most appropriate and specific exceptions they can. Throwing specific exceptions makes it easier to debug applications. Consider the following example using an SplDoublyLinkedList where an attempt is made to access an out-of-bounds index, to set an index using a class, and to call pop on an empty container:
    <?php
    $linkedList = new SplDoublyLinkedList();
     
    try {
        $linkedList[1];
    } catch(Exception $error) {
        echo get_class($error) . ': ' . $error->getMessage() . "\n";
    }
     
    try {
        $linkedList[new StdClass()] = 'class';
    } catch(Exception $error) {
        echo get_class($error) . ': ' . $error->getMessage() . "\n";
    }
     
    try {
        $linkedList->pop();
    } catch(Exception $error) {
        echo get_class($error) . ': ' . $error->getMessage() . "\n";
    }
    ?>

    The result:

    OutOfRangeException: Offset invalid or out of range
    OutOfRangeException: Offset invalid or out of range
    RuntimeException: Can't pop from an empty datastructure
    1. Accessing an out-of-bounds index led to an incorrect exception type of OutOfRangeException, a child of LogicException. The actual problem encountered was not a logical exception, but a runtime one.
    2. Trying to set an index using an invalid type (a class) led to an OutOfRangeException. The name is ambiguous, but the meaning is correct. The message that the exception provides is the real problem here. It does not provide what went wrong but presents two options.
    3. Popping from an empty container caused a generic RuntimeException to be thrown. The more correct exception would be UnderflowException.
  • The data-structures violate good programming practices.
    • SplStack and SplQueue. SplStack and SplQueue are fully exposed SplDoublyLinkedLists. 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.
    • SplObjectStorage. SplObjectStorage violates the idea of single responsibility. It is performing duties as a Map and a Set. The API is difficult to use because of this dual-identity.

Proposal

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 when you call bottom, peek, pop, shift, and top on an empty container.
    • SplFixedArray:
      • Should throw OutOfBoundsException when an index that is a valid type but is out-of-bounds is used in any operation.
      • Should throw OverflowException 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 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 extension in the Spl should well defined and documented. This includes using an example of when the exception could be used. All of the Spl classes should be refactored to align their behavior with the result of this discussion. 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.
  • APIs of SplStack and SplQueue. This author believes that their APIs should be trimmed back. 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.
rfc/spl-improvements.1324285210.txt.gz · Last modified: 2017/09/22 13:28 (external edit)