# Proposal: namespace the SPL

- Thread: https://externals.io/message/113141
- Original archive: https://news-web.php.net/php.internals/113141
- Started by Levi Morrison on 2021-02-11T16:39:16+00:00
- Messages: 17
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #113141 — Levi Morrison — 2021-02-11T16:39:16+00:00

URL: https://externals.io/message/113141#113141

Hello, everyone,

There has been a lot of disagreement about namespacing, and people
seem to have different viewpoints. I am not sure how to reconcile this
broader discussion.

However, there are certain names in the global namespace which I am
hopeful we can revolve. For instance, `SplObserver`, `SplQueue`,
`SplFixedArray`, etc all follow the `Spl` prefix. There is already an
established "namespace" for these names.

So here is my limited proposal:
 1. We create names in the `Spl` namespace that are aliases to their
equivalent types with the `Spl` prefix:
    `Spl\FixedArray` -> SplFixedArray
    `Spl\Queue` -> SplQueue
     a. The new names are the aliases so any code which uses
`get_class($obj)` will not have the name change on them in a minor
release (8.1).
     b. We may switch the direction of this alias in 9.0.
 2. Any new types going into `ext/spl` use the `Spl` namespace. New
types added to `ext/spl` should be either related to data structures
or iterators, which is the bulk of what the SPL is.
     a. This rule is to help prevent the SPL from becoming the dumping
grounds for new types.
 3. We leave functions alone for now.

Let me know what you think. I am hopeful this approach will work because:
 1. It is focused on a specific area which already has an established
"namespace", but in name-only (not technically).
 2. It does not try to solve the larger problem, which has a lot of
disagreement.
 3. 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.

---

## #113142 — Mark Randall — 2021-02-11T16:57:16+00:00

URL: https://externals.io/message/113141#113142 · In reply to: #113141

> Let me know what you think. I am hopeful this approach will work because:
>   1. It is focused on a specific area which already has an established
> "namespace", but in name-only (not technically).
>   2. It does not try to solve the larger problem, which has a lot of
> disagreement.
>   3. 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.

Mark Randall

---

## #113143 — Levi Morrison via internals — 2021-02-11T17:23:06+00:00

URL: https://externals.io/message/113141#113143

>
> 
> > […]
>
> 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.

I agree, which is the point of accepting things in a narrow scope.
Data structures and iterators go hand-in-hand, as many iterator
implementations are directly connected to the internal implementation
details of the related data structure. There are other iterators, and
as long as they are general purpose they are fine too. These things
are related, not unrelated.

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

As mentioned in the previous point, iterators and data structures
belong together. It does not make sense to separate the implementation
of FixedArray and its iterator into two different namespaces; they are
one cohesive unit.

Lastly, if we don't adopt a namespace soon, what will new names be? I
can guarantee it will be something like `SplReverseIterator`, not
`SplIteratorReverseIterator`. It won't be
`SplDatastructureCachedIterable`, it would be something like
`SplCachedIterable` (or `CachedIterable`, ugh).

As you see, "Spl" _is_ the namespace. Any more or any less is
incongruent with what we have. This is why I am hopeful that
_specifically_ using "Spl" for these specific types can reach
agreement; all we are changing is `Spl$thing` to `Spl\$thing`.

---

## #113144 — Chase Peeler — 2021-02-11T17:48:25+00:00

URL: https://externals.io/message/113141#113144 · In reply to: #113143

On Thu, Feb 11, 2021 at 12:23 PM Levi Morrison via internals <
internals@lists.php.net> wrote:

> 
> > […]
> because:
> > […]
>
> I agree, which is the point of accepting things in a narrow scope.
> Data structures and iterators go hand-in-hand, as many iterator
> implementations are directly connected to the internal implementation
> details of the related data structure. There are other iterators, and
> as long as they are general purpose they are fine too. These things
> are related, not unrelated.
>
> > […]
>
> As mentioned in the previous point, iterators and data structures
> belong together. It does not make sense to separate the implementation
> of FixedArray and its iterator into two different namespaces; they are
> one cohesive unit.
>
> Lastly, if we don't adopt a namespace soon, what will new names be? I
> can guarantee it will be something like `SplReverseIterator`, not
> `SplIteratorReverseIterator`. It won't be
> `SplDatastructureCachedIterable`, it would be something like
> `SplCachedIterable` (or `CachedIterable`, ugh).
>
> As you see, "Spl" _is_ the namespace. Any more or any less is
> incongruent with what we have. This is why I am hopeful that
> _specifically_ using "Spl" for these specific types can reach
> agreement; all we are changing is `Spl$thing` to `Spl\$thing`.
>
>
I think Spl makes sense (there might be a debate over whether it should be
Spl or SPL though). How feasible is it to create generate a deprecation
notice when the global version is used? I assume the hope is to eventually
move away from using those, and I don't think that's a horrible BC break
given that users have enough time to prepare for it.


> --
> 
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

-- 
Chase Peeler
chasepeeler@gmail.com

---

## #113145 — Levi Morrison via internals — 2021-02-11T17:54:53+00:00

URL: https://externals.io/message/113141#113145 · In reply to: #113144

>
>
>
> 
> > […]
>
> I think Spl makes sense (there might be a debate over whether it should be Spl or SPL though). How feasible is it to create generate a deprecation notice when the global version is used? I assume the hope is to eventually move away from using those, and I don't think that's a horrible BC break given that users have enough time to prepare for it.

I don't know the answer to that question. However, I don't think we
should add a deprecation on the very first version that we add the
aliases anyway. I think that would make for a bad upgrade experience
from 8.0 to 8.1. I would leave that more for 8.3, 8.4-ish in the
release cycle so there are at least a few versions for people to
organically change their code without triggering any notices of any
kind.

> > […]
>
>
> --
> Chase Peeler
> chasepeeler@gmail.com

---

## #113146 — Lynn — 2021-02-11T18:08:32+00:00

URL: https://externals.io/message/113141#113146 · In reply to: #113145

On Thu, Feb 11, 2021 at 6:55 PM Levi Morrison via internals <
internals@lists.php.net> wrote:

> I don't know the answer to that question. However, I don't think we
> should add a deprecation on the very first version that we add the
> aliases anyway. I think that would make for a bad upgrade experience
> from 8.0 to 8.1. I would leave that more for 8.3, 8.4-ish in the
> release cycle so there are at least a few versions for people to
> organically change their code without triggering any notices of any
> kind.
>

I would very much prefer this to be deprecated in the same version. This
way you prevent the confusion of which of the two to use and have people
implement the one we already know is going to be removed. Deprecations do
not make it a bad upgrade experience at all. Quite the opposite in my
opinion, they hint to me nice and early on which parts of the code base I
have to adjust. The earlier the better.

---

## #113147 — Rowan Tommins — 2021-02-11T18:29:24+00:00

URL: https://externals.io/message/113141#113147 · In reply to: #113141

>   2. Any new types going into `ext/spl` use the `Spl` namespace. New
> types added to `ext/spl` should be either related to data structures
> or iterators, which is the bulk of what the SPL is.
>       a. This rule is to help prevent the SPL from becoming the dumping
> grounds for new types.


I think having this rule mentioned and agreed somewhere at least is a 
good idea.

We could perhaps in future look at moving those parts currently labelled 
as "spl" which *don't* fall into those categories somewhere else. It's 
weird that you can now _only_ use autoloading via a function prefixed 
"spl_", even though it's a language feature.

Regards,

-- 
Rowan Tommins
[IMSoP]

---

## #113148 — Chase Peeler — 2021-02-11T18:32:12+00:00

URL: https://externals.io/message/113141#113148 · In reply to: #113146

>
>
> On Thu, Feb 11, 2021 at 6:55 PM Levi Morrison via internals <
> internals@lists.php.net> wrote:
>
> > […]
>
> I would very much prefer this to be deprecated in the same version. This
> way you prevent the confusion of which of the two to use and have people
> implement the one we already know is going to be removed. Deprecations do
> not make it a bad upgrade experience at all. Quite the opposite in my
> opinion, they hint to me nice and early on which parts of the code base I
> have to adjust. The earlier the better.
>

I'm really ambivalent about when they are introduced, but I actually think
I agree with you. I know it's very much just a personal anecdote, but since
I don't turn deprecation notices on until I'm ready to actually look for
and fix them, I don't find them obtrusive at all.


-- 
Chase Peeler
chasepeeler@gmail.com

---

## #113166 — Pierre — 2021-02-13T16:25:20+00:00

URL: https://externals.io/message/113141#113166 · In reply to: #113144

Le 11/02/2021 à 18:48, Chase Peeler a écrit :
> I think Spl makes sense (there might be a debate over whether it should be
> Spl or SPL though). How feasible is it to create generate a deprecation
> notice when the global version is used? I assume the hope is to eventually
> move away from using those, and I don't think that's a horrible BC break
> given that users have enough time to prepare for it.

Hello,

For what it worth, I think that Spl is both ugly to read (yes, I like 
things not only to be semantic, but elegant as well) and hard to type on 
my keyboard (OK subjective point here, both are actually).

"Spl" does mean somethings, but I'd prefer something more generic such 
as "std" or "standard" or "system", or even "stdlib". And it's an 
opinion, and we all have one. Even having lowercased namespace names for 
PHP standard library wouldn't bother me much: it would make it 
consistent in reading (e.g. `use std\array\first` for example, vs 
\array_first()` vs `use Spl\Array\first`). OK stupid point here, but 
fact is I don't really care, I just try to make a point here: we are 
free to invent new things, or get old things from other languages. We 
have all the possibilities of the world and beyond offering themselves 
to us, the only limit is our imagination.

I disagree about narrow scope: if we / you don't think about the future, 
each narrow iteration will only get more and more inconsistent, each 
step will be a flame ware about naming, and no convention or consistency 
will emerge. And it will be slow. I will retire before I'll see an Array 
class or a `collection` namespace. And I'm not even that old! This will 
fatigue people, and kill any kind of good faith or good sense we still 
yet have.

I think that namespacing, even if its implementation starts narrow (this 
make sense) should be thought thoroughly with a wider scope, with a 
global scheme even more. It should be voted with a complete view of what 
it will become, and how that makes stuff consistent across the whole 
actual and future SPL.

I know this has not much chances to happen, because people always 
disagree for purely subjective reasons (beauty of names, ease of typing, 
semantic meaning of stuff, weird keyboard layout, or just because some 
people don't like when it's other people's ideas which get to be chosen 
or voted for) anyhow, I think that narrow scope will only gets PHP 
standard library farther from its goal than help it.

This was my 2 cents,

Best regards,

--

Pierre

---

## #113167 — Levi Morrison via internals — 2021-02-13T17:01:46+00:00

URL: https://externals.io/message/113141#113167 · In reply to: #113166

>
> Le 11/02/2021 à 18:48, Chase Peeler a écrit :
> > […]
>
> Hello,
>
> For what it worth, I think that Spl is both ugly to read (yes, I like
> things not only to be semantic, but elegant as well) and hard to type on
> my keyboard (OK subjective point here, both are actually).
>
> "Spl" does mean somethings, but I'd prefer something more generic such
> as "std" or "standard" or "system", or even "stdlib". And it's an
> opinion, and we all have one. Even having lowercased namespace names for
> PHP standard library wouldn't bother me much: it would make it
> consistent in reading (e.g. `use std\array\first` for example, vs
> \array_first()` vs `use Spl\Array\first`). OK stupid point here, but
> fact is I don't really care, I just try to make a point here: we are
> free to invent new things, or get old things from other languages. We
> have all the possibilities of the world and beyond offering themselves
> to us, the only limit is our imagination.
>
> I disagree about narrow scope: if we / you don't think about the future,
> each narrow iteration will only get more and more inconsistent, each
> step will be a flame ware about naming, and no convention or consistency
> will emerge. And it will be slow. I will retire before I'll see an Array
> class or a `collection` namespace. And I'm not even that old! This will
> fatigue people, and kill any kind of good faith or good sense we still
> yet have.
>
> I think that namespacing, even if its implementation starts narrow (this
> make sense) should be thought thoroughly with a wider scope, with a
> global scheme even more. It should be voted with a complete view of what
> it will become, and how that makes stuff consistent across the whole
> actual and future SPL.
>
> I know this has not much chances to happen, because people always
> disagree for purely subjective reasons (beauty of names, ease of typing,
> semantic meaning of stuff, weird keyboard layout, or just because some
> people don't like when it's other people's ideas which get to be chosen
> or voted for) anyhow, I think that narrow scope will only gets PHP
> standard library farther from its goal than help it.
>
> This was my 2 cents,
>
> Best regards,
>
> --
>
> Pierre
>
> --
> 
> To unsubscribe, visit: https://www.php.net/unsub.php
>

You make some good points, Pierre. Here are my main rebuttals:

 1. "Spl" is already the effective namespace for the SPL because
that's the prefix used by SplFixedArray, SplQueue, spl_classes, and so
on. Its namespace has already been de facto chosen.

 2. We have two proposals adding new things to the SPL for 8.1, so we
need to decide if they are going into ext/spl as 1. \Spl\Thing, 2.
\SplThing, or 3. \Thing. Keeping the wider vision in mind is a great
principle, but we need to decide on these new additions _now_ despite
not reaching consensus on the wider thing.

Obviously, I'm hopeful we can agree on using the Spl namespace for
these additions, and any future SPL additions.

  [1]: https://wiki.php.net/rfc/any_all_on_iterable#vote

---

## #113168 — Pierre R. — 2021-02-13T17:57:34+00:00

URL: https://externals.io/message/113141#113168 · In reply to: #113167

Le 13/02/2021 à 18:01, Levi Morrison via internals a écrit :
> You make some good points, Pierre. Here are my main rebuttals:
>
>   1. "Spl" is already the effective namespace for the SPL because
> that's the prefix used by SplFixedArray, SplQueue, spl_classes, and so
> on. Its namespace has already been de facto chosen.
>
>   2. We have two proposals adding new things to the SPL for 8.1, so we
> need to decide if they are going into ext/spl as 1. \Spl\Thing, 2.
> \SplThing, or 3. \Thing. Keeping the wider vision in mind is a great
> principle, but we need to decide on these new additions _now_ despite
> not reaching consensus on the wider thing.
>
> Obviously, I'm hopeful we can agree on using the Spl namespace for
> these additions, and any future SPL additions.
>
>    [1]: https://wiki.php.net/rfc/any_all_on_iterable#vote

Aside of the fact I don't like "Spl" if a good naming convention comes 
out with it prefixing all namespaces so be it and I'll be happy. One 
thing that bother me much in the current proposal is those kind of 
classes: `Spl\FixedArray -> SplFixedArray`.

That's the most important point in my eyes, it should be already named 
with a deeper namespace, such as:

`Spl\[Collection|List]\{FixedArray,Vector,Queue,LinkedList,...}`

in order to make space for later other namespaces to take their rightful 
place, such as:

`Spl\Security\{PasswordHash,RandomNumberGenerator,...}` or

`Spl\[Io|File|FileSystem]\{FileBuffer,DirectoryIterator}`.

Even if it starts with a narrow scope, it *must*, in my opinion, make 
space for later additions, therefore `Spl\` must be considered as being 
the "PHP standard library root namespace", in that regard, no classes or 
functions must live at root, they must be segregated in their own 
sub-namespace. If we don't do this, we will very much regret it later.

Regards,

--

Pierre

---

## #113169 — Levi Morrison via internals — 2021-02-13T19:45:04+00:00

URL: https://externals.io/message/113141#113169 · In reply to: #113168

>
> Le 13/02/2021 à 18:01, Levi Morrison via internals a écrit :
> > […]
>
> Aside of the fact I don't like "Spl" if a good naming convention comes
> out with it prefixing all namespaces so be it and I'll be happy. One
> thing that bother me much in the current proposal is those kind of
> classes: `Spl\FixedArray -> SplFixedArray`.
>
> That's the most important point in my eyes, it should be already named
> with a deeper namespace, such as:
>
> `Spl\[Collection|List]\{FixedArray,Vector,Queue,LinkedList,...}`
>
> in order to make space for later other namespaces to take their rightful
> place, such as:
>
> `Spl\Security\{PasswordHash,RandomNumberGenerator,...}` or
>
> `Spl\[Io|File|FileSystem]\{FileBuffer,DirectoryIterator}`.
>
> Even if it starts with a narrow scope, it *must*, in my opinion, make
> space for later additions, therefore `Spl\` must be considered as being
> the "PHP standard library root namespace", in that regard, no classes or
> functions must live at root, they must be segregated in their own
> sub-namespace. If we don't do this, we will very much regret it later.
>
> Regards,
>
> --
>
> Pierre
>
> --
> 
> To unsubscribe, visit: https://www.php.net/unsub.php
>

To be clear, I am arguing that `Spl` be the namespace for future
additions to `ext/spl`, and that we alias a few existing types for
consistency. Just as `ext/spl` is not the whole PHP standard library
(just one small part of it), the `Spl` namespace I am proposing is not
the "PHP standard library root namespace" either; it's just the
namespace for the bits in `ext/spl`.

What you are arguing for was the subject of recent namespacing
proposals, which failed to reach consensus. I am intentionally
proposing a different solution for a much narrower problem hoping it
will stick, so that new additions going into the ext/spl can avoid
having this naming discussion every time.

---

## #113171 — tyson andre — 2021-02-14T22:44:36+00:00

URL: https://externals.io/message/113141#113171 · In reply to: #113169

Hi internals,

> > […]

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

> > […]

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.

> > […]
> 
> 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`](https://www.php.net/manual/en/book.ds.php)
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

---

## #113172 — Levi Morrison via internals — 2021-02-15T00:51:43+00:00

URL: https://externals.io/message/113141#113172 · In reply to: #113171

Oof, this is a long one. I'm going to snip some of it  but respond to
most things privately; I will also respond to some things publicly
later.


>
> Hi internals,
>
> > […]
>
> 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.

<snip>

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

I will write a formal RFC this week, and it will include all of the
proposed aliases (unless the sentiment is that we don't want them; I
talk about this a bit more later in this email).

> **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\`.**

This is a logical conclusion from how it was worded, but it's not what
I meant. I meant to say that ext/spl is open for contributions in
certain spaces:
 1. Generic data structures and their iterators. (not highly specific
ones, like a hypothetical LaravelEventQueue).
 2. Generic iterators.
 3. File oriented types (I omitted this originally, but it was unintentional)

Anyone can propose new additions to ext/spl and if they are in that
scope (and maybe a few more like exceptions, we'll see), but they
aren't forced to go into the SPL. It probably makes sense to add it to
the SPL, but if there was a large proposal, like an iterable oriented
library with over a dozen symbols, then I'm sure a case can be made
for putting it somewhere else too.

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

In my opinion, we shouldn't be adding very many symbols to the global
namespace that are unprefixed. Things should be namespaced either by
using a real namespace (preferred) or by a prefix. That isn't to say I
would outright ban it -- there could be perhaps new core interfaces
that may make sense to go there if they interact with the language in
special ways. Or at least, they belong in the global namespace by
status quo until we can agree on an official namespace policy for
such.

>   I would find it inconsistent to use the Spl naming scheme both for classes with extremely old design decisions
>   from php 5.3 <snip>

This does not bother me, but I would also be open to not aliasing
existing types if that would make people happier. If we don't alias
the existing types, then there will be a small `Spl` namespace with
only newer additions (which are probably of higher overall quality
than the prefixed versions). I am okay with this, but sometimes people
feel like this kind of thing is too small in scope.

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

Yes, the SPL is not fully consistent. Some of these things have moved
out of the SPL over time (such as the Countable interface).  Most data
structures are prefixed, but no iterators are. In other words, it has
some warts but at least mostly has a pattern going. As mentioned
earlier, I think nearly all new symbols need to be namespaced or
prefixed, so I think it's worth breaking the no-prefix, no-namespace
tradition of the iterators for new iterator types (at least concrete
ones; there may be room for new interfaces in the core language).

---

## #113173 — Levi Morrison via internals — 2021-02-15T01:03:04+00:00

URL: https://externals.io/message/113141#113173 · In reply to: #113172

On Sun, Feb 14, 2021 at 5:51 PM Levi Morrison
<levi.morrison@datadoghq.com> wrote:
>
> Oof, this is a long one. I'm going to snip some of it  but respond to
> most things privately; I will also respond to some things publicly
> later.
>
> 
> > […]
>
> <snip>
>
> > […]
>
> I will write a formal RFC this week, and it will include all of the
> proposed aliases (unless the sentiment is that we don't want them; I
> talk about this a bit more later in this email).
>
> > […]
>
> This is a logical conclusion from how it was worded, but it's not what
> I meant. I meant to say that ext/spl is open for contributions in
> certain spaces:
>  1. Generic data structures and their iterators. (not highly specific
> ones, like a hypothetical LaravelEventQueue).
>  2. Generic iterators.
>  3. File oriented types (I omitted this originally, but it was unintentional)
>
> Anyone can propose new additions to ext/spl and if they are in that
> scope (and maybe a few more like exceptions, we'll see), but they
> aren't forced to go into the SPL. It probably makes sense to add it to
> the SPL, but if there was a large proposal, like an iterable oriented
> library with over a dozen symbols, then I'm sure a case can be made
> for putting it somewhere else too.
>
> > […]
>
> In my opinion, we shouldn't be adding very many symbols to the global
> namespace that are unprefixed. Things should be namespaced either by
> using a real namespace (preferred) or by a prefix. That isn't to say I
> would outright ban it -- there could be perhaps new core interfaces
> that may make sense to go there if they interact with the language in
> special ways. Or at least, they belong in the global namespace by
> status quo until we can agree on an official namespace policy for
> such.
>
> > […]
>
> This does not bother me, but I would also be open to not aliasing
> existing types if that would make people happier. If we don't alias
> the existing types, then there will be a small `Spl` namespace with
> only newer additions (which are probably of higher overall quality
> than the prefixed versions). I am okay with this, but sometimes people
> feel like this kind of thing is too small in scope.
>
> > […]
>
> Yes, the SPL is not fully consistent. Some of these things have moved
> out of the SPL over time (such as the Countable interface).  Most data
> structures are prefixed, but no iterators are. In other words, it has
> some warts but at least mostly has a pattern going. As mentioned
> earlier, I think nearly all new symbols need to be namespaced or
> prefixed, so I think it's worth breaking the no-prefix, no-namespace
> tradition of the iterators for new iterator types (at least concrete
> ones; there may be room for new interfaces in the core language).

Oops, didn't send it privately after all. That's fine; I was just
going to try to be more concise and general for the public one.

---

## #113207 — Levi Morrison via internals — 2021-02-18T14:48:47+00:00

URL: https://externals.io/message/113141#113207 · In reply to: #113141

>
> Hello, everyone,
>
> There has been a lot of disagreement about namespacing, and people
> seem to have different viewpoints. I am not sure how to reconcile this
> broader discussion.
>
> However, there are certain names in the global namespace which I am
> hopeful we can revolve. For instance, `SplObserver`, `SplQueue`,
> `SplFixedArray`, etc all follow the `Spl` prefix. There is already an
> established "namespace" for these names.
>
> So here is my limited proposal:
>  1. We create names in the `Spl` namespace that are aliases to their
> equivalent types with the `Spl` prefix:
>     `Spl\FixedArray` -> SplFixedArray
>     `Spl\Queue` -> SplQueue
>      a. The new names are the aliases so any code which uses
> `get_class($obj)` will not have the name change on them in a minor
> release (8.1).
>      b. We may switch the direction of this alias in 9.0.
>  2. Any new types going into `ext/spl` use the `Spl` namespace. New
> types added to `ext/spl` should be either related to data structures
> or iterators, which is the bulk of what the SPL is.
>      a. This rule is to help prevent the SPL from becoming the dumping
> grounds for new types.
>  3. We leave functions alone for now.
>
> Let me know what you think. I am hopeful this approach will work because:
>  1. It is focused on a specific area which already has an established
> "namespace", but in name-only (not technically).
>  2. It does not try to solve the larger problem, which has a lot of
> disagreement.
>  3. 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.
>
> --
> 
> To unsubscribe, visit: https://www.php.net/unsub.php
>

There's been a lull in feedback, so let me steer it towards a specific
point that was brought up: how do you feel about adding aliases from
\Spl\Thing to \SplThing?

https://strawpoll.com/22pcxh69p

---

## #113247 — Levi Morrison via internals — 2021-02-24T16:27:13+00:00

URL: https://externals.io/message/113141#113247 · In reply to: #113207

On Thu, Feb 18, 2021 at 7:48 AM Levi Morrison
<levi.morrison@datadoghq.com> wrote:
>
> 
> > […]
>
> There's been a lull in feedback, so let me steer it towards a specific
> point that was brought up: how do you feel about adding aliases from
> \Spl\Thing to \SplThing?
>
> https://strawpoll.com/22pcxh69p

It's been about a week. Current standings out of 33 total votes:
"I think they are important to the proposal." => 16 votes (~48%)
"I prefer them to not be aliased." => 11 votes (~33%)
"I don't care about them." => 6 votes (~18%)

I'll think more about the discussion so far and these results and then
either adjust or drop the proposal.