Despite every SPL method now living within the official PHP documentation, much needs to be done.

If the method in the SPL class does not overwrite them, or introduce changes, then there is no need to document them specifically again as they are already documented within the interface. Simply not documenting them will make the docs of the interface available on the class reference page as we specifically list the class name of which the method is implemented in, so it should be obvious that they do whatever the interface says they do.

Really the only loss here is these then go missing within the side navigation bar. Handle this?

If the class overwrites a method, by convention it is normally documented separately. However, a lot of overlap generally still exists; e.g. key() methods are pretty uniform in behaviour even if implemented separately. Notes, See Also, ??? to link to the common information?

Some example areas to consider:

• Common Iterator methods: current, key, next, rewind, valid
• OuterIterator interface: getInnerIterator
• Classes implementing Countable, RecursiveIterator, SeekableIterator
• What about non-SPL interfaces (e.g. ArrayAccess, Serializable)

Much of the remaining 'skeleton' SPL docs fall into this category of common methods so it would be worth having a plan of action on this subject before ploughing ahead with those.

• Tutorial like chapters. This will show useful tasks that combine several methods. Example: “How to create a nested html list of files and directories”
• Tips and tricks, using SPL
• FAQ: Example: ordering of next() current() reset() ...
• Examples, see section below

Each class should have an example within the __construct() documentation, but also a basic example within the main class page. Additional examples (likely, more complex ones) will live within an example specific section for each class. For example, the SplFixedArray documentation has a basic example above the TOC, and we like this. Additional ones would live within its own page, within the SplFixedArray documentation.

This idea requires additional thought, but it involves grouping methods by interface. It would probably need to be done manually, which would involve not using the magical &refrence.extname.classname.functions; type entities. However, one risk forgetting about this while adding new SPL methods meaning they won't show up.