Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109836
MIME-Version: 1.0
References: <CANOvohpz5OzHZSxdABncBXRQfeF-XnKqpK8BBDQ8OeT+jBL96w@mail.gmail.com>
 <5ea1aab8.1c69fb81.72671.791bSMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <5ea1aab8.1c69fb81.72671.791bSMTPIN_ADDED_MISSING@mx.google.com>
Date: Fri, 24 Apr 2020 18:00:32 -0500
Message-ID: <CAEUnE0fjMpGyEwGorseuGvpnB1cJfA6uspRT6MSQX06zCxy0Ow@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d2537c05a411557d"
Subject: Re: [PHP-DEV] Re: [RFC] PHP Namespace Policy
From: tendoaki@gmail.com (Michael Morris)

--000000000000d2537c05a411557d
Content-Type: text/plain; charset="UTF-8"

On Thu, Apr 23, 2020 at 9:48 AM Mark Randall <marandall@php.net> wrote:

> On 15/04/2020 12:21, Mark Randall wrote:
> > https://wiki.php.net/rfc/php_namespace_policy
>
> Just an update in light of the two different RFCs.
>
> Having chatted with the other RFC authors in R11, rather than racing to
> see who can get their RFC to vote first, it seems like there's room for
> both.
>
> Vote 1 would be the other RFC which would be something along the lines of:
>
> "Mandate the use of \PHP for future internal tightly-bound components"
>
> If vote 1 were passed, the next vote would be on this RFC, and would
> cover policy on namespace usage and would be something like:
>
> "The \PHP namespace must remain empty, except for child namespaces".
>
> This would be to prevent the problem of colliding internals symbols
> throughout the rest of PHP's maintained lifespan (such as what if there
> was something else added to core called Token).
>
> Vote 3 would mandate only autoloadable classes / interfaces / traits etc
> etc were used, allowing userland polyfills (where sensible) to provide a
> route for users to begin using newer API functionality without an
> immediate upgrade.
>
> Votes 1 and 2 passing would put us on a pretty good course for long-term
> sanity.
>
> Vote 1 passing and 2 failing would result in part of the problem just
> being moved to \PHP and exposing us to symbol collision further down the
> line.
>
> If vote 1 failed, we would have to consider if this RFC would pass with
> its tigher constraints.
>
> The question is, how would we vote on extra uses for PHP.
>
> While the alternative RFC mandates its use for tightly coupled, I think
> it makes a lot of sense to add extra things to it, such as re-designed
> collections (borg Ds?) in \PHP\Collections in a similar fashion to:
>
>
> https://docs.microsoft.com/en-us/dotnet/api/system.collections?view=netframework-4.8
>
>
> Mark Randall
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I would like to submit from the peanut gallery of user land. My perspective
here is as a user, not as an internals writer. I also have no formal
training so I can bring that perspective to the table for consideration.
That said, I don't represent anyone but myself.

I've read the talk of how the \PHP namespace should be used and not be
used. I personally think we should slow down and carefully consider what we
can do here, because active assignment of the namespace will have
ramifications for the rest of PHP's life. We have the opportunity to make a
course change, but it won't be easy. And we only really get one good shot
at this.

All of PHP's core functionality is currently in \.  All of it. That makes
the language easy to pick up and learn, but the functions in that namespace
are, well, idiosyncratic.  Are the arguments in (haystack, needle) order or
(needle, haystack).  Is the function camelCase or underscore_delimited or
neitherone?

Changing function names and argument orders would lead to BC breaks so
massive people would move away without a transition plan that was
sustainable long term.  Namespaces give that opportunity, I think.

So, in steps:

1. Take the current function roster - all of it - and put it in
\PHP\Legacy\.  So the formal name of strpos would become
\PHP\Legacy\strpos.
2. The root namespace would be empty BUT...
3. An INI directive set globally or per directory can set which namespace
is bound to root.  Initially this would be "\PHP\Legacy", so all legacy
code would not have to change - it would run in the new version and find
all of its functionality without incident.  This is critical - as this
directive would likely need to stay as is for two majors minimum, possibly
more.

And yes, I'm keenly aware of the scope of this.  The RFC system itself
would need to be changed to allow this to be possible since this approach
demands a design be submitted, approved and THEN an implementation written
and approved. Difficult, but not impossible - the W3C does this all the
time. Even with a Design, then implement RFC system in place, I imagine a
full year would be needed just to get the designs down and agreed upon.
The best PHP 8 could do is just lay the foundation for transition outlined
above and not actually include any alternative to \PHP\Legacy

The rest of \PHP\ would be the replacements for the legacy pieces.  It
needs to be a designed library with a consistent naming schema and argument
orders, at a minimum. It also needs to be broken up so as not to overwhelm
the developers doing the implementation. We might even end up with some
duplication to satisfy the procedural vs. object oriented camps. The new
functions would also have a freer hand since they are opted into.

Beyond that though I don't really think it's helpful for me to go into more
detail because I'm not a language designer. I know enough to know I don't
know enough to give this subject a thorough vetting at this time (I could
certainly learn). The specifics of implementation though are out of scope -
what is in scope is the mechanism of transition. We have a golden
opportunity here.

I guess what I'm asking is, where do we want to go with this?  If we aren't
doing something with the legacy functions as part of this I feel it's just
another layer of confusion and frustration for end users like me.  There
has to be a clear rhyme and reason to be putting things into the \PHP\
namespace.

Again, since there's nothing there right now we get one shot at this. Once
things start going in there they'll have to be supported in perpetuity. So
let's think very, very carefully, about what goes in and how - please.

--000000000000d2537c05a411557d--