[RFC][DISCUSSION] PHP Namespace in core

5 years ago by michal.brzuchalski@gmail.com — view source — reply

unread

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

5 years ago by G. P. B. — view source — reply

unread

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

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

5 years ago by Derick Rethans — view source — reply

unread

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

5 years ago by michal.brzuchalski@gmail.com — view source — reply

unread

Hi Derick,

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

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:

Traversable, Iterator, IteratorAggregate - cause these are used in
foreach statements
ArrayAccess - cause this one is required to accept r/w by dimension
(offset* - methods)
Serializable, __PHP_Incomplete_Class ?! - cause this is used in
serializing/deserializing and this is bound to magic methods in classes
stdClass - cause this is a default class of the object which is produced
when an array is cast to (object)
Closure, Generator - cause these are also tightly coupled with the engine
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

5 years ago by G. P. B. — view source — reply

unread

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

5 years ago by Derick Rethans — view source — reply

unread

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

5 years ago by G. P. B. — view source — reply

unread

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

5 years ago by Marcio Almada — view source — reply

unread

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

5 years ago by michal.brzuchalski@gmail.com — view source — reply

unread

Hi Marcio,

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

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

5 years ago by Andrea Faulds — view source — reply

unread

Hi,

Michał Brzuchalski wrote:

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

5 years ago by G. P. B. — view source — reply

unread

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

5 years ago by Benjamin Eberlei — view source — reply

unread

Hi Michał, George,

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

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

5 years ago by Mike Schinkel — view source — reply

unread

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

5 years ago by michal.brzuchalski@gmail.com — view source — reply

unread

Hi Mike

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

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

5 years ago by michal.brzuchalski@gmail.com — view source — reply

unread

Hi Benjamin,

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

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

5 years ago by G. P. B. — view source — reply

unread

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

5 years ago by michal.brzuchalski@gmail.com — view source — reply

unread

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 michal.brzuchalski@gmail.com
napisał(a):

5 years ago by G. P. B. — view source — reply

unread

The proposal is not to move everything into the PHP namespace.
I would even argue that these interface make more sense in the global
namespace as they are meant to be available to all users to implement
and extend.

This is in strong contract to the Reflection API which, at least, should not
be extended by end users IMHO as it provided features which are heavily
tied to the engine and how it is implemented.
Now as Reflection is already an existing feature the objective here is not
to move the current one into the PHP namespace and alias it but possibly
provide a Reflection 2.0 API which is design with the benefit of hindsight.

A more relevant example, in my eyes, is the current proposal of attributes.
Engine attributes like JIT, NoJIT, and possibly in the future Deprecated
and/
or Final are features provided by the engine which should not have the
possibility to be extended by end users, only consumed.

Another example I can come up are scalar objects.
If PHP starts to provided scalar objects, I would imagine that they it won't
be possible to extend them and only consume them, in the same way as
the current functions provided by ext/standard.
Or maybe a new API to interact with stream and/or the file system.

I hope this clarifies the intent behind the RFC.

Best regards

George P. Banyard

5 years ago by Rowan Tommins — view source — reply

unread

I don't really understand the distinction here. We currently have many
interfaces which exist to trigger "magic" in the Engine, some of which even
have special restrictions on how they can be used (e.g. you can't actually
implement Throwable or Traversable).

If we want to prevent users extending an attribute like JIT or NoJIT, we
can just mark the relevant class "final", and while extending ArrayAccess
or Countable is possible it isn't a particularly common use case, so that
doesn't seem like a meaningful difference.

If ArrayAccess didn't exist yet, and was proposed after this RFC was
accepted, my interpretation of the text would be that it must be placed in
the \PHP namespace, because it is "tightly coupled to the internals/engine
of the PHP interpreter".

Regards,

Rowan Tommins
[IMSoP]