Proposal: namespace the SPL

Hi internals,

1b. We may switch the direction of this alias in 9.0.

The new names for existing Spl types at least seem more readable and possible to polyfill with class_alias.
It should be clarified if "data types" include interfaces such as https://www.php.net/manual/en/class.splobserver
but I assume it does.

A minor concern is that the wider switch on a case-by-case basis to namespacing will collectively add a
lot of small barriers for end users that are upgrading (especially with external libraries/applications),
but agree that starting out small is the best way to discuss it.

• e.g. data serialize()d and put into memcached or a database by PHP 9.0
  could not be read from memcached by servers still running PHP 8.0,
  and this would unexpectedly result in PHP_Incomplete_Class
  and new users may need to do a lot of research to figure out how to avoid/fix this
  (by calling class_alias in 8.0).

Let me know what you think. I am hopeful this approach will work because:

I support voting on this separately from adding new functionality.

To clarify my earlier decisions, I had strong reservations about introducing new functionality and setting a de facto precedent for a namespace policy in the same vote
on https://wiki.php.net/rfc/any_all_on_iterable (but did so anyway due to feedback of multiple voters suggesting widespread opposition to continuing global namespacing months ago),
because the deciding factor in a vote on new functions or new classes for voters may have been
"do I (dislike the namespacing choice used in this RFC) less than (I dislike not having this useful proposed enhancement added to PHP)."
and am happier with your plan to create an RFC asking "do 2/3rds of people think this namespace choice should be used for future additions to ext/spl."

In my decision to independently gather feedback for https://wiki.php.net/rfc/any_all_on_iterable_straw_poll_namespace
I was deliberately overcommunicating knowing that:

1. If it passed, the namespacing policy choices made there might be interpreted or insisted on
   as a precedent for future additions to the Spl (or even PHP in general) for a long time.

   This may cause a tolerable namespace choice to be used for many future additions to ext/spl, rather than the one preferred by most of internals,
   which is why I was only fine with starting a vote after gathering feedback from https://wiki.php.net/rfc/any_all_on_iterable_straw_poll_namespace

2. If it was voted on without gathering widespread feedback on overall namespace preferences,
   I'd expect even more No votes and the function namespacing discussion could continually get reopened if some namespace permutation wasn't even an option.

   I apologize for the 11-way straw poll.
   Many voters do not comment on the internals mailing list, e.g. if someone else has already said the same thing.

Let me know what you think. I am hopeful this approach will work because:

It is focused on a specific area which already has an established
"namespace", but in name-only (not technically).
It does not try to solve the larger problem, which has a lot of
disagreement.
I will be proposing new types for ext/spl soon (ReverseIterator
and an array iterator that is more efficient than \ArrayIterator),
and Tyson Andre has already proposed CachedIterable and company
which is in ext/spl, so this space has active development.
Thank you for your time.

Do you want a dumping ground? Because this is how you create a dumping
ground :-)

If we're going to start putting things into namespaces (and we should)
then we should absolutely avoid repeating the mistakes of the past by
dumping completely unrelated things together.

If SPL\ is to exist (and personally I think SPL is so cancerous, it
shouldn't) then IMO it must absolutely be SPL\iterators.

Without that all we've done is swap one problem for another.

The idea of putting data structures next to generic iterator helpers is,
quite frankly, nuts.

Do you have an expected timeline for creating the RFC document for this proposal and starting the vote?
A vote would greatly reduce the uncertainty and time/energy involvement of proposing
adding additional datastructures, benefiting contributors both familiar and unfamiliar
with the PHP RFC process, and I agree with Levi that it would be useful to ensure that
"new additions going into the ext/spl can avoid having this naming discussion every time."

My main objection to the proposal is that this forces
all core generic datastructures to go in the Spl namespace
indefinitely, or would entail the creation of a separate module and splitting up the php.net manual pages to document new built-in datastructures
that don't begin with SPL\.
Right now, the collection of classes in SPL is fairly small - it's used in library code but rarely used directly,
but if PHP were to add a collection of datastructures similar to php-ds
then end users would use the naming much more often.

I'd agree that the prefix Spl in class/interface names has a large number of negative connotations for those who
are familiar with it and my impression was that there'd be less than 2/3 support for a proposal to adopt it,
due to those negative connotations, the wide range of preferred namespace choices, and anticipations for future namespacing choices in PHP.
(Right now, I'm not even sure about 2/3rds for any proposed namespace change)
For those that aren't familiar with it, the name SPL may be hard to remember,
especially after namespaces get introduced for existing and new extensions.
For example, a well-known issue is that
https://www.php.net/manual/en/class.splstack.php extends SplDoublyLinkedList and implements Iterator
and isn't final, meaning:

1. It is impractical to change for backwards compatibility reasons,

2. A doubly-linked list wastes memory and is slower for common operrations compared to something backed by an array.

3. Can't independently iterate over it while another iteration is in place and iteration has unknown side effects.

   From user notes, "the SplStack is simply a SplDoublyLinkedList with an iteration mode IT_MODE_LIFOs and IT_MODE_KEEP`"

4. If this RFC were to pass, what would we call a more memory/cpu efficient array-based list, stack, or queue? Spl\ArrayQueue?

5. Consequently, many people prefer plain arrays over spl datastructures.

I haven't actually checked, but I'd assumed at the time, some prefix (i.e. Spl) was chosen to avoid conflicting with user-defined Stack/Queue/other, etc.,
and that early on with namespaces only being introduced in PHP 5.3 it would have been easier to create polyfills (for PHP 5.2)
if namespaces weren't used - it was an acceptable prefix, not the best naming convention.

If we were to enforce that all new datastructures introduced
into SPL started with SPL I'd have to consider moving the CachedIterable proposal to ext/std or a
new always-enabled module such as std_ds for classes introduced in PHP 8,
but if it turns out there's widespread support for the namespace choicing of Spl\...ForwardArrayIterator
I would very likely go with Spl\...CachedIterable.

• I'd proposed CachedIterable, not SplCachedIterable.

• It'd force a choice between inconsistencies.

  I would find it inconsistent to use the Spl naming scheme both for classes with extremely old design decisions
  from php 5.3 made because they were easy to implement (non-final, linked lists, custom iteration behaviors, Iterator instead of IteratorAggregate,
  memory inefficiencies), etc with the new objects.

  It'd also be inconsistent to have two different sections in the PHP manual for datastructures because of a constraint on the folder ext/spl.
  I guess phasing out SplStack and so on to switch to recommending brand new redesigned datastructures such as PHP\std\Vector or PHP\ds\Vector
  would be another option.

• Right now, SPL is a mix of classes/interfaces/functions prefixed with Spl and those that aren't,
  if you look at https://www.php.net/manual/en/book.spl.php ,
  SPL already has data structures such as ArrayObject and interfaces that aren't prefixed.

Unrelatedly to this proposal,
I feel like the internals mailing list may end up repeating a lot of small namespacing discussions the next time someone
proposes adding a class to a different module despite the lack of consensus, whether or not the RFC passes.

• There haven't been any class addition RFCs
  to extensions other than SPL in the last 4 months (i.e. after SPL namespacing was brought up)
  so it's too early to say if that's the case in practice.

My opinion is that this situation may stall or prevent the proposal and addition of future types to PHP's existing modules,
especially if small namespace policy votes repeatedly get slightly less than 2/3 approval and keep getting amended and re-proposed for different existing modules.

For example, if a hypothetical new contributor (John Jorgesson) were to create an
RFC adding "\GMPRational" for fractions with arbitrary-precision numerators and denominators (rational numbers),
and there (hypothetically) was broad support for adding GMPRational in php-src (I'm not proposing adding GMPRational):

Someone who may or may not be involved with implementing GMPRational might suggest that that new contributor
start working on the broader proposal of migrating GMP to use namespaces
and all of the naming discussion that entails before there's a widely accepted namespacing policy
(e.g. discussion on moving GMP to GMP\GMP or GMP\BigInt or PHP\BigInt or PHP\GMP\BigInt), either leading to

1. Adding GMP namespacing changes to the proposal, significantly raising the duration, time and energy involvement
   beyond what John expected for the original proposal,
   and John's RFC facing a effectively steeper threshold than to pass because votes against adding datatypes are mixed with votes against the particular namespace choice
   (e.g. potentially setting a bad precedent or being done before namespace policy consensus was made.)
2. Keeping the proposal in the global namespace and facing a much steeper threshold to pass because
   votes against adding datatypes are mixed with votes made on principle against NOT namespacing by voters who otherwise may not have voted on GMP RFCs.
3. John Jorgesson abandoning the RFC process, possibly creating a PECL instead for something that (hypothetically) should have been in php-src.

Regards,
Tyson