On Thu, Apr 23, 2020 at 9:48 AM Mark Randall <marand...@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.
