[RFC][DISCUSSION] PHP Namespace in core

  109651
April 15, 2020 12:29 michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)
Hi internals,

I hope you're doing well.

I'd like to announce the PHP Namespace in core RFC for discussion.
The RFC is authored by me together with George Peter Banyard and it's
purpose
is nothing more like to allow the use of PHP Namespace in the core.

The RFC is described at https://wiki.php.net/rfc/php-namespace-in-core

Best Regards,
Michał Brzuchalski
  109652
April 15, 2020 12:34 george.banyard@gmail.com ("G. P. B.")
On Wed, 15 Apr 2020 at 14:29, Michał Brzuchalski <
michal.brzuchalski@gmail.com> wrote:

> Hi internals, > > I hope you're doing well. > > I'd like to announce the PHP Namespace in core RFC for discussion. > The RFC is authored by me together with George Peter Banyard and it's > purpose > is nothing more like to allow the use of PHP Namespace in the core. > > The RFC is described at https://wiki.php.net/rfc/php-namespace-in-core > > Best Regards, > Michał Brzuchalski >
Well this is unfortunate that another similar RFC just has been announced. However, we are open to feedback and will monitor the other thread too. Best regards George P. Banyard
  109656
April 15, 2020 13:51 derick@php.net (Derick Rethans)
On Wed, 15 Apr 2020, Micha=C5=82 Brzuchalski wrote:

> Hi internals, >=20 > I hope you're doing well. >=20 > I'd like to announce the PHP Namespace in core RFC for discussion. > The RFC is authored by me together with George Peter Banyard and it's > purpose > is nothing more like to allow the use of PHP Namespace in the core.
I think a "may" is not a clever way forwards. I think that if you want=20 to use the PHP namespace for engine specific things (like=20 Attribute/Token), then they must all use that, or none. cheers, Derick --=20 PHP 7.4 Release Manager Host of PHP Internals News: https://phpinternals.news Like Xdebug? Consider supporting me: https://xdebug.org/support https://derickrethans.nl | https://xdebug.org | https://dram.io twitter: @derickr and @xdebug
  109661
April 15, 2020 17:07 michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)
Hi Derick,

śr., 15 kwi 2020 o 15:51 Derick Rethans <derick@php.net> napisał(a):

> On Wed, 15 Apr 2020, Michał Brzuchalski wrote: > > > Hi internals, > > > > I hope you're doing well. > > > > I'd like to announce the PHP Namespace in core RFC for discussion. > > The RFC is authored by me together with George Peter Banyard and it's > > purpose > > is nothing more like to allow the use of PHP Namespace in the core. > > I think a "may" is not a clever way forwards. I think that if you want > to use the PHP namespace for engine specific things (like > Attribute/Token), then they must all use that, or none. >
You mean if we want to introduce PHP namespace we should also propose immediately to move engine specific things (like Attribute/Token) into proposal? If so then we should search for the rest of engine specific things which will include then many interfaces and classes like: 1. Traversable, Iterator, IteratorAggregate - cause these are used in foreach statements 2. ArrayAccess - cause this one is required to accept r/w by dimension (offset* - methods) 3. Serializable, __PHP_Incomplete_Class ?! - cause this is used in serializing/deserializing and this is bound to magic methods in classes 4. stdClass - cause this is a default class of the object which is produced when an array is cast to (object) 5. Closure, Generator - cause these are also tightly coupled with the engine 6. Throwable, etc. - just for consistency with the rest from https://www.php.net/manual/en/reserved.classes.php and https://www.php.net/manual/en/reserved.interfaces.php Is that what you mean? Cheers, Michał Brzuchalski
  109665
April 15, 2020 19:36 george.banyard@gmail.com ("G. P. B.")
On Wed, 15 Apr 2020 at 15:51, Derick Rethans <derick@php.net> wrote:

> On Wed, 15 Apr 2020, Michał Brzuchalski wrote: > > > Hi internals, > > > > I hope you're doing well. > > > > I'd like to announce the PHP Namespace in core RFC for discussion. > > The RFC is authored by me together with George Peter Banyard and it's > > purpose > > is nothing more like to allow the use of PHP Namespace in the core. > > I think a "may" is not a clever way forwards. I think that if you want > to use the PHP namespace for engine specific things (like > Attribute/Token), then they must all use that, or none. > > cheers, > Derick > > -- > PHP 7.4 Release Manager > Host of PHP Internals News: https://phpinternals.news > Like Xdebug? Consider supporting me: https://xdebug.org/support > https://derickrethans.nl | https://xdebug.org | https://dram.io > twitter: @derickr and @xdebug > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
Just to clarify is this limited to new features or should this also be applied to current engine features? If only the former I personally don't mind making it a requirement. Best regards George P. Banyard
  109669
April 15, 2020 20:27 derick@php.net (Derick Rethans)
On 15 April 2020 20:36:25 BST, "G. P. B." banyard@gmail.com> wrote:
>On Wed, 15 Apr 2020 at 15:51, Derick Rethans <derick@php.net> wrote: > >> On Wed, 15 Apr 2020, Michał Brzuchalski wrote: >> >> > Hi internals, >> > >> > I hope you're doing well. >> > >> > I'd like to announce the PHP Namespace in core RFC for discussion. >> > The RFC is authored by me together with George Peter Banyard and >it's >> > purpose >> > is nothing more like to allow the use of PHP Namespace in the core. >> >> I think a "may" is not a clever way forwards. I think that if you >want >> to use the PHP namespace for engine specific things (like >> Attribute/Token), then they must all use that, or none. >> > >Just to clarify is this limited to new features or should this also be >applied to current engine features? >If only the former I personally don't mind making it a requirement.
Everything introduced for PHP 8 and later. I can't think of such an engine related item like Attribute / Token from earlier versions however. Can you? cheers, Derick
  109670
April 15, 2020 20:38 george.banyard@gmail.com ("G. P. B.")
On Wed, 15 Apr 2020 at 22:27, Derick Rethans <derick@php.net> wrote:

> On 15 April 2020 20:36:25 BST, "G. P. B." banyard@gmail.com> > wrote: > >On Wed, 15 Apr 2020 at 15:51, Derick Rethans <derick@php.net> wrote: > > > >> On Wed, 15 Apr 2020, Michał Brzuchalski wrote: > >> > >> > Hi internals, > >> > > >> > I hope you're doing well. > >> > > >> > I'd like to announce the PHP Namespace in core RFC for discussion. > >> > The RFC is authored by me together with George Peter Banyard and > >it's > >> > purpose > >> > is nothing more like to allow the use of PHP Namespace in the core. > >> > >> I think a "may" is not a clever way forwards. I think that if you > >want > >> to use the PHP namespace for engine specific things (like > >> Attribute/Token), then they must all use that, or none. > >> > > > >Just to clarify is this limited to new features or should this also be > >applied to current engine features? > >If only the former I personally don't mind making it a requirement. > > > Everything introduced for PHP 8 and later. I can't think of such an engine > related item like Attribute / Token from earlier versions however. Can you? > > cheers, > Derick >
Other than ext/Reflexion, not really. I've amended the RFC [1] to use "must" instead of "may". Best regards George P. Banyard [1] https://wiki.php.net/rfc/php-namespace-in-core
  109659
April 15, 2020 16:38 marcio.web2@gmail.com (Marcio Almada)
> > Hi internals, > > I hope you're doing well. > > I'd like to announce the PHP Namespace in core RFC for discussion. > The RFC is authored by me together with George Peter Banyard and it's > purpose > is nothing more like to allow the use of PHP Namespace in the core. > > The RFC is described at https://wiki.php.net/rfc/php-namespace-in-core > > Best Regards, > Michał Brzuchalski
Hello, Even though I'm fond to the idea of languages having the official stdlib contained into a single space, there seems to be no practicality on a \PHP namespace usage at this point IMMO. We would be in a situation where things are either mixed in and out the new namespace - Should I `use function PHP\{json_encode, json_decode}` or was it in the root??? - or everything that already exists must first receive an alias into this new namespace, to allow consistency... but then there would probably be no plans ever to actually move existing stuff into the new prefix in the future. With the lack of a feasible roadmap, I'd rather vote on doing nothing for now :/ Thanks, Márcio
  109660
April 15, 2020 16:49 michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)
Hi Marcio,

śr., 15 kwi 2020 o 18:39 Marcio Almada web2@gmail.com> napisał(a):

> > > > Hi internals, > > > > I hope you're doing well. > > > > I'd like to announce the PHP Namespace in core RFC for discussion. > > The RFC is authored by me together with George Peter Banyard and it's > > purpose > > is nothing more like to allow the use of PHP Namespace in the core. > > > > The RFC is described at https://wiki.php.net/rfc/php-namespace-in-core > > > > Best Regards, > > Michał Brzuchalski > > Hello, > > Even though I'm fond to the idea of languages having the official > stdlib contained > into a single space, there seems to be no practicality on a \PHP namespace > usage > at this point IMMO. > > We would be in a situation where things are either mixed in and out > the new namespace > - Should I `use function PHP\{json_encode, json_decode}` or was it in > the root??? - or > everything that already exists must first receive an alias into this > new namespace, to allow > consistency... but then there would probably be no plans ever to > actually move existing stuff > into the new prefix in the future. > > You've misunderstood the idea. Standard library functions classes etc. are
not language features. It's not a purpose of this RFC to move existing functions from the standard library but to allow core language features to use it. Described examples show benefit in use for symbols tightly coupled to features PHP as a language delivers. Most of the standard library function can be replaced by implementations in PHP or by wrapping around a C library. The features tightly coupled with the language is for eg. the Reflection mechanism, PhpToken class as described. Upcoming PhpAttributes for which proposal is a work in progress. Those all features will not likely be moved to PECL and this RFC proposal is to allow features like that to use PHP namespace. Cheers, Michał Brzuchalski
  109663
April 15, 2020 17:24 ajf@ajf.me (Andrea Faulds)
Hi,

Michał Brzuchalski wrote:
> Hi Marcio, > > śr., 15 kwi 2020 o 18:39 Marcio Almada web2@gmail.com> napisał(a): > >> Even though I'm fond to the idea of languages having the official >> stdlib contained >> into a single space, there seems to be no practicality on a \PHP namespace >> usage >> at this point IMMO. >> >> We would be in a situation where things are either mixed in and out >> the new namespace >> - Should I `use function PHP\{json_encode, json_decode}` or was it in >> the root??? - or >> everything that already exists must first receive an alias into this >> new namespace, to allow >> consistency... but then there would probably be no plans ever to >> actually move existing stuff >> into the new prefix in the future. >> >> > You've misunderstood the idea. Standard library functions classes etc. are > not language features. > It's not a purpose of this RFC to move existing functions from the standard > library but to allow core language features > to use it. Described examples show benefit in use for symbols tightly > coupled to features PHP as a language delivers. > > Most of the standard library function can be replaced by implementations in > PHP or by wrapping around a C library. > The features tightly coupled with the language is for eg. the Reflection > mechanism, PhpToken class as described. > Upcoming PhpAttributes for which proposal is a work in progress. > > Those all features will not likely be moved to PECL and this RFC proposal > is to allow features like that to use PHP namespace.
We already have PHP language features relying on classes in the root namespace (Closure, Throwable, ArrayAccess, etc) so the point Marcio makes about inconsistency is nonetheless valid I think. Thanks, Andrea
  109666
April 15, 2020 19:39 george.banyard@gmail.com ("G. P. B.")
On Wed, 15 Apr 2020 at 18:39, Marcio Almada web2@gmail.com> wrote:

> > > > Hi internals, > > > > I hope you're doing well. > > > > I'd like to announce the PHP Namespace in core RFC for discussion. > > The RFC is authored by me together with George Peter Banyard and it's > > purpose > > is nothing more like to allow the use of PHP Namespace in the core. > > > > The RFC is described at https://wiki.php.net/rfc/php-namespace-in-core > > > > Best Regards, > > Michał Brzuchalski > > Hello, > > Even though I'm fond to the idea of languages having the official > stdlib contained > into a single space, there seems to be no practicality on a \PHP namespace > usage > at this point IMMO. > > We would be in a situation where things are either mixed in and out > the new namespace > - Should I `use function PHP\{json_encode, json_decode}` or was it in > the root??? - or > everything that already exists must first receive an alias into this > new namespace, to allow > consistency... but then there would probably be no plans ever to > actually move existing stuff > into the new prefix in the future. > > With the lack of a feasible roadmap, I'd rather vote on doing nothing for > now :/ > > Thanks, > Márcio > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > As mentioned by Michal, JSON is not a core engine extension, you can even
compile a version of PHP without JSON support therefore compared to the parallel discussion this extension would not be included in the PHP namespace. Best regards George P. Banyard
  109716
April 20, 2020 12:06 kontakt@beberlei.de (Benjamin Eberlei)
Hi Michał, George,

On Wed, Apr 15, 2020 at 2:29 PM Michał Brzuchalski <
michal.brzuchalski@gmail.com> wrote:

> Hi internals, > > I hope you're doing well. > > I'd like to announce the PHP Namespace in core RFC for discussion. > The RFC is authored by me together with George Peter Banyard and it's > purpose > is nothing more like to allow the use of PHP Namespace in the core. > > The RFC is described at https://wiki.php.net/rfc/php-namespace-in-core
I think the php namespace for core is important to have, especially for features that have more than a single, but multiple classes, grouping them in a PHP internal namespace will be helpful to avoid weird prefixing. With the Attributes RFC in mind, an earlier draft has used the namespace PHP\Attributes that a few contributors rightly mentioned is a bad idea without project wide standardization first. For my taste, the RFC is great except the "A chance to clean up poor design/naming decisions" section. It goes into politics and controversial ideas that essentially are outside the scope of the RFC itself. So while SPL and Reflection would benefit if we had the namespace before those APIs, I am not sure they drive down the point of why we need this: a.) Instead of changing SPL I believe most would pretty much agree that we just need a complete replacement with a better API (pointing towards phpds here might be a better example) b.) Moving some new parts of Reflection into the namespace while keeping others in the main namespace is extremely confusing, and we shouldn't confuse users that way. Realistically this is an issue thats not going to be changed. I do like the Frame example, similar to token_get_all returning an array, debug_backtrace could benefit from an object based representation. I would reluctantly call it a "toy example", it is an actual example or not? greetings Benjamin
> > > Best Regards, > Michał Brzuchalski >
  109739
April 21, 2020 05:29 mike@newclarity.net (Mike Schinkel)
I have been wondering for a while why PHP does not officially recognize a \PHP namespace.

The inconsistency people have mentioned feels like a fair tradeoff for allowing new core classes to be cleanly-named and easier to understand.

And a \PHP namespace would allow RFCs to never need worry about conflicting with userland class names again.  

The one thing I would ask the authors: 

- Why limit it to "tightly coupled to the PHP engine?" 
- Why not just say "any new core classes that are approved to use it?"

After all, sometimes a namespace is just a namespace. Seems like a winner to me.

-Mike
  109740
April 21, 2020 07:19 michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)
Hi Mike

wt., 21 kwi 2020 o 07:29 Mike Schinkel <mike@newclarity.net> napisał(a):

> I have been wondering for a while why PHP does not officially recognize a > \PHP namespace. > > The inconsistency people have mentioned feels like a fair tradeoff for > allowing new core classes to be cleanly-named and easier to understand. > > And a \PHP namespace would allow RFCs to never need worry about > conflicting with userland class names again. > > The one thing I would ask the authors: > > - Why limit it to "tightly coupled to the PHP engine?" > - Why not just say "any new core classes that are approved to use it?"
In the past, there were some proposals which treated about core namespace proposing to include most of the core symbols in a structured way. These proposals always failed for some reason. This proposal tries to convince internals to use PHP namespace in the core for tightly coupled to the PHP engine types which could be placed there without a risk to be unbundled in a future what would cause a need to rename them back. Therefore we think that these along with the arguments in the proposal are the best ones to agree for now. BR, Michał Brzuchalski
  109741
April 21, 2020 07:31 michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)
Hi Benjamin,

pon., 20 kwi 2020 o 14:06 Benjamin Eberlei <kontakt@beberlei.de> napisał(a):

> Hi Michał, George, > > On Wed, Apr 15, 2020 at 2:29 PM Michał Brzuchalski < > michal.brzuchalski@gmail.com> wrote: > >> Hi internals, >> >> I hope you're doing well. >> >> I'd like to announce the PHP Namespace in core RFC for discussion. >> The RFC is authored by me together with George Peter Banyard and it's >> purpose >> is nothing more like to allow the use of PHP Namespace in the core. >> >> The RFC is described at https://wiki.php.net/rfc/php-namespace-in-core > > > I think the php namespace for core is important to have, especially for > features that have more than a single, but multiple classes, grouping them > in a PHP internal namespace will be helpful to avoid weird prefixing. > > With the Attributes RFC in mind, an earlier draft has used the namespace > PHP\Attributes that a few contributors rightly mentioned is a bad idea > without project wide standardization first. > > For my taste, the RFC is great except the "A chance to clean up poor > design/naming decisions" section. It goes into politics and controversial > ideas that essentially are outside the scope of the RFC itself. So while > SPL and Reflection would benefit if we had the namespace before those APIs, > I am not sure they drive down the point of why we need this: > > a.) Instead of changing SPL I believe most would pretty much agree that we > just need a complete replacement with a better API (pointing towards phpds > here might be a better example) > b.) Moving some new parts of Reflection into the namespace while keeping > others in the main namespace is extremely confusing, and we shouldn't > confuse users that way. Realistically this is an issue thats not going to > be changed. > > I do like the Frame example, similar to token_get_all returning an array, > debug_backtrace could benefit from an object based representation. I would > reluctantly call it a "toy example", it is an actual example or not? >
The example with the Frame is something I'm thinking about to propose and implement. About the changing SPL. Bear in mind that the current proposal is only about an agreement to allow the use of PHP namespace in the core. @Benjamin: You suggest to skip the examples and arguments regarding poor design/naming decisions with Reflection API ? Those examples are put in the RFC to help understand the argumentation and the result of this RFC should be the agreement that any future RFC proposing an introduction of the tightly coupled with the PHP engine symbol (and to mention the ones with PhpToken and PhpAttribute and family could be perfect candidates) should not worry for the proposal to be rejected because of the use of PHP namespace in core symbols. BR, Michał Brzuchalski
  109808
April 23, 2020 12:16 george.banyard@gmail.com ("G. P. B.")
Hello everyone,

We've updated the RFC [1] by rewriting it in part and trying to add more
details
/context and trying to address some other concerns which came up.

Hoping for some more feedback before planning on moving this to a vote.

Best regards

George P. Banyard

[1] https://wiki.php.net/rfc/php-namespace-in-core
  110228
May 21, 2020 05:12 michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)
Hi Internals,

I'm really sorry for the long delay on this topic.

I think it's time to vote since there seems like no further discussion is
needed.

*So head's up!* I plan to open this topic for a vote.
The vote will be simple Yes/No and requires to be accepted by 2/3 votes as
always.

Voting will open Tomorrow on *May 22nd around 06:00 UTC*
and will remain open for 14 days until *4th of June.*

Cheers,
--
Michał Marcin Brzuchalski
/For the fame and glory of PHP!!/


śr., 15 kwi 2020 o 14:29 Michał Brzuchalski brzuchalski@gmail.com>
napisał(a):

> Hi internals, > > I hope you're doing well. > > I'd like to announce the PHP Namespace in core RFC for discussion. > The RFC is authored by me together with George Peter Banyard and it's > purpose > is nothing more like to allow the use of PHP Namespace in the core. > > The RFC is described at https://wiki.php.net/rfc/php-namespace-in-core > > Best Regards, > Michał Brzuchalski >