Everything

php

Home » Project » Newsgroups » php.internals » [RFC] [Discussion] Namespaces in Core »

[RFC] [Discussion] Namespaces in Core

php.internals

Fleshgrinder

9 years ago

Next promised RFC (and the last one for this weekend):

https://wiki.php.net/rfc/namespaces-in-core

I am unsure about whether we should avoid the usage of abbreviations for
things like language (lang), standard (std), and utility (util). I think
it is not necessary to write them out fully, but, well, ...?!?

--
Richard "Fleshgrinder" Fussenegger

Fleshgrinder

9 years ago

On 6/3/2017 6:40 PM, Fleshgrinder wrote:

> Next promised RFC (and the last one for this weekend):
>
> https://wiki.php.net/rfc/namespaces-in-core
>
> I am unsure about whether we should avoid the usage of abbreviations for
> things like language (lang), standard (std), and utility (util). I think
> it is not necessary to write them out fully, but, well, ...?!?
>

Bump, would love some feedback on the RFC and the open issues. Otherwise
this goes into voting and lots of complains pop up. It would be much
more efficient to use the discussion time for that.

--
Richard "Fleshgrinder" Fussenegger

Levi Morrison

9 years ago

On Sat, Jun 10, 2017 at 12:11 PM, Fleshgrinder <php@fleshgrinder.com> wrote:

> On 6/3/2017 6:40 PM, Fleshgrinder wrote:
>> Next promised RFC (and the last one for this weekend):
>>
>> https://wiki.php.net/rfc/namespaces-in-core
>>
>> I am unsure about whether we should avoid the usage of abbreviations for
>> things like language (lang), standard (std), and utility (util). I think
>> it is not necessary to write them out fully, but, well, ...?!?
>>
>
> Bump, would love some feedback on the RFC and the open issues. Otherwise
> this goes into voting and lots of complains pop up. It would be much
> more efficient to use the discussion time for that.
>
> --
> Richard "Fleshgrinder" Fussenegger
>

I gave this feedback before but I'll repeat it. I support namespaces
in the core, with the `PHP` namespace (with whatever capitalization we
decide) to be reserved *solely* for things related to the language
itself such as lexer, parser, etc.

I am fine with other extensions using namespaces but should use
appropriately named ones. Using the `PHP` namespace to indicate
something is packaged in core is a poor decision. We have moved
existing extensions into core and it would not make sense to rename it
simply because it was moved into core because it's a backwards
compatibility break. Similarly we've moved at least one extension out
of core and it doesn't make sense for it to have the `PHP` name when
it's not in core, but renaming it is yet other backwards compatibility
break. It's simply not prudent. Instead extensions should be named
after what they are, the vendor they are for, or some other name; this
is the same process user-land packages go through and core should not
be different.

Fleshgrinder

9 years ago

On 6/10/2017 8:54 PM, Levi Morrison wrote:

> I gave this feedback before but I'll repeat it. I support namespaces
> in the core, with the `PHP` namespace (with whatever capitalization we
> decide) to be reserved *solely* for things related to the language
> itself such as lexer, parser, etc.
>
> I am fine with other extensions using namespaces but should use
> appropriately named ones. Using the `PHP` namespace to indicate
> something is packaged in core is a poor decision. We have moved
> existing extensions into core and it would not make sense to rename it
> simply because it was moved into core because it's a backwards
> compatibility break. Similarly we've moved at least one extension out
> of core and it doesn't make sense for it to have the `PHP` name when
> it's not in core, but renaming it is yet other backwards compatibility
> break. It's simply not prudent. Instead extensions should be named
> after what they are, the vendor they are for, or some other name; this
> is the same process user-land packages go through and core should not
> be different.
>

Thanks for that, much appreciated.

This is exactly what I am proposing. Only things that are provided
directly from the PHP Group should go into the PHP namespace. Any- and
everything else should go into appropriate vendor namespaces.

I think that you are considering e.g. array functions as not being part
of PHP, and that you want to put them in a separate namespace. So
effectively we would have something like:

PHP\Lexer
Arrays\Array
IO\File
Logging\Logger
Reflection\Reflector
Strings\String
UUIDs\UUID

I personally do not like this approach. PHP is the vendor of these
things, thus, it should reside in the namespace of the vendor. Same
rules for everyone. IO for instance is not a vendor, it is a particular
use-case (working with files) and thus should not go directly into the
global namespace.

There is imho no reason to move `PHP\Reflection\Reflector` to
`Reflection\Reflector` just because we decided, for whatever reason, to
remove reflection from core and instead providing it via PECL. PHP would
still be the vendor of it.

The misconception that I am seeing is, that the PHP namespace is bound
to PHP, which it isn't: it is the vendor namespace of the PHP Group.

The PHP community at large has settled with this approach, and I believe
that it is a very good approach. It effectively avoids namespace
collisions and helps to identify the vendor of a particular implementation.

Would love to hear what others think about this.

--
Richard "Fleshgrinder" Fussenegger

Levi Morrison

9 years ago

On Sat, Jun 10, 2017 at 1:13 PM, Fleshgrinder <php@fleshgrinder.com> wrote:

> On 6/10/2017 8:54 PM, Levi Morrison wrote:
>> I gave this feedback before but I'll repeat it. I support namespaces
>> in the core, with the `PHP` namespace (with whatever capitalization we
>> decide) to be reserved *solely* for things related to the language
>> itself such as lexer, parser, etc.
>>
>> I am fine with other extensions using namespaces but should use
>> appropriately named ones. Using the `PHP` namespace to indicate
>> something is packaged in core is a poor decision. We have moved
>> existing extensions into core and it would not make sense to rename it
>> simply because it was moved into core because it's a backwards
>> compatibility break. Similarly we've moved at least one extension out
>> of core and it doesn't make sense for it to have the `PHP` name when
>> it's not in core, but renaming it is yet other backwards compatibility
>> break. It's simply not prudent. Instead extensions should be named
>> after what they are, the vendor they are for, or some other name; this
>> is the same process user-land packages go through and core should not
>> be different.
>>
>
> Thanks for that, much appreciated.
>
> This is exactly what I am proposing. Only things that are provided
> directly from the PHP Group should go into the PHP namespace. Any- and
> everything else should go into appropriate vendor namespaces.
>
> I think that you are considering e.g. array functions as not being part
> of PHP, and that you want to put them in a separate namespace. So
> effectively we would have something like:
>
>     PHP\Lexer
>     Arrays\Array
>     IO\File
>     Logging\Logger
>     Reflection\Reflector
>     Strings\String
>     UUIDs\UUID
>
> I personally do not like this approach. PHP is the vendor of these
> things, thus, it should reside in the namespace of the vendor. Same
> rules for everyone. IO for instance is not a vendor, it is a particular
> use-case (working with files) and thus should not go directly into the
> global namespace.
>
> There is imho no reason to move `PHP\Reflection\Reflector` to
> `Reflection\Reflector` just because we decided, for whatever reason, to
> remove reflection from core and instead providing it via PECL. PHP would
> still be the vendor of it.
>
> The misconception that I am seeing is, that the PHP namespace is bound
> to PHP, which it isn't: it is the vendor namespace of the PHP Group.
>
> The PHP community at large has settled with this approach, and I believe
> that it is a very good approach. It effectively avoids namespace
> collisions and helps to identify the vendor of a particular implementation.
>
> Would love to hear what others think about this.
>
> --
> Richard "Fleshgrinder" Fussenegger
>

If we were starting from scratch maybe we'd do as you are proposing.
However, there is absolutely zero value in these specific things being
namespaced *anywhere*:

- Arrays
- Reflection
- Strings
- IO

We already have established conventions and prefixes around these.
Moving them to a namespace has zero value.

I'm not sure what logging you are talking about for PHP.

That leaves UUID, which I am fine with having its own namespace if
there are enough functions, constants, classes, etc to support it.

Fleshgrinder

9 years ago

On 6/10/2017 9:24 PM, Levi Morrison wrote:

> If we were starting from scratch maybe we'd do as you are proposing.
> However, there is absolutely zero value in these specific things being
> namespaced *anywhere*:
>
>   - Arrays
>   - Reflection
>   - Strings
>   - IO
>
> We already have established conventions and prefixes around these.
> Moving them to a namespace has zero value.
>
> I'm not sure what logging you are talking about for PHP.
>
> That leaves UUID, which I am fine with having its own namespace if
> there are enough functions, constants, classes, etc to support it.
>

These are examples!?!

I see no reason to limit our thoughts and imagination here. This is a
proposal for the future of PHP, for whatever might come. Limiting us
seems more than counterproductive to me.

Array, Bool, Int, Float, String, ... all of them are valid things to
think about. Not only as an intellectual game, but also in the light of
_scalar objects_ [1].

[1] https://github.com/nikic/scalar_objects

PS: Moving of anything that already exists was never mentioned, implied,
or part of the proposal. This is something Levi just brought up and I
want to repudiate myself in the strongest terms from moving anything!

--
Richard "Fleshgrinder" Fussenegger

Levi Morrison

9 years ago

On Sat, Jun 10, 2017 at 1:34 PM, Fleshgrinder <php@fleshgrinder.com> wrote:

> On 6/10/2017 9:24 PM, Levi Morrison wrote:
>> If we were starting from scratch maybe we'd do as you are proposing.
>> However, there is absolutely zero value in these specific things being
>> namespaced *anywhere*:
>>
>>   - Arrays
>>   - Reflection
>>   - Strings
>>   - IO
>>
>> We already have established conventions and prefixes around these.
>> Moving them to a namespace has zero value.
>>
>> I'm not sure what logging you are talking about for PHP.
>>
>> That leaves UUID, which I am fine with having its own namespace if
>> there are enough functions, constants, classes, etc to support it.
>>
>
> These are examples!?!
>
> I see no reason to limit our thoughts and imagination here. This is a
> proposal for the future of PHP, for whatever might come. Limiting us
> seems more than counterproductive to me.
>
> Array, Bool, Int, Float, String, ... all of them are valid things to
> think about. Not only as an intellectual game, but also in the light of
> _scalar objects_ [1].
>
> [1] https://github.com/nikic/scalar_objects
>
> PS: Moving of anything that already exists was never mentioned, implied,
> or part of the proposal. This is something Levi just brought up and I
> want to repudiate myself in the strongest terms from moving anything!
>
> --
> Richard "Fleshgrinder" Fussenegger
>

You put out namespaces for them which implies you think we might do that.

Fleshgrinder

9 years ago

On 6/10/2017 11:11 PM, Levi Morrison wrote:

> You put out namespaces for them which implies you think we might do that.
>

Erm ... not really ... I am sorry if my examples lead to a confusion on
your side.

Let's try this the other way around. What are *other extensions* for you?

--
Richard "Fleshgrinder" Fussenegger

Dan Ackroyd

9 years ago

Hi 'Fleshgrinder',

I object to this RFC on principle.

RFC's are supposed to be opionated. They are supposed to present an
argument for why we should do something, and why doing that is a good
idea.

This RFC does not do that; it presents a series of questions to vote
on, without any clear presentation of what problem they are solving or
why people should be vote for the RFC.

Asking people to vote on things like this, leads to choice being made
at random, when there may not even be a need to make a choice in the
first place.

These parts of the RFC are particularly lacking justification:

> Allow plural nouns in namespaces? Yes/No
> Use namespace for the language itself (in the future)? Yes/No
> Name of the language namespace? core/lang
> Use namespace for tiny self-encapsulated things (in the future)? Yes/No
> Name of that namespace? std/util

In addition, there are problems with other parts of the RFC.

> Coding Standard? snake_case/PascalCase

Shouldn't this be part of the other RFC?

> This could help to avoid those 1,000+ LOC files

Splitting files to only contain related things is a good idea.
Splitting related things into separate files, just because some
arbitrary line limit has been reached, is not.


From the RFC:

> Introduce namespaces to user-level symbols to avoid collisions with user defined symbols
>
> Use namespace for the language itself (in the future)? Yes/No
>

From email, Fleshgrinder wrote:

> I personally do not like this approach. PHP is the vendor of these
> things, thus, it should reside in the namespace of the vendor. Same
> rules for everyone.

If this is actually problem, a better solution might be just reserve
the global namespace in addition to the 'PHP' namespace. However the
RFC does not say why it is a problem that needs addressing, and so we
cannot explore possible solutions.

Multiple people have given you feedback that your idea of using a top
level 'PHP' vendor namespace isn't a good match for the project.
Rather than rephrasing what they have already said, I will just remind
you of an earlier reply:

From http://news.php.net/php.internals/98225
On 2/6/2017 9:47 PM, Nikita Popov wrote:

>
> I'm strongly against use of the PHP namespace as a blanket namespace
> for bundled PHP extensions. The PHP namespace should be used only
> for functionality that is actually in some way related to PHP. For
> example, the php-ast extension could reasonably be namespaced as
> php\ast, as it provides an AST for PHP specifically. Similarly the
> tokenizer extension could reasonably be namespaced as php\tokenizer.
>
> Extensions which are not of this type should not live in the PHP
> namespace, because they don't have anything specifically to do with
> php, apart from the circumstance that they happen to be bundled at
> the current point in time. Remember that extension may move from
> being bundled to being in PECL and vice versa. If we decide to bundle
> the MongoDB extension with php, would we rename the currently used
> MongoDB namespace to PHP\MongoDB? If we decided to move it back to
> PECL, would the namespace go back to just MongoDB? Or would it stay
> PHP\MongoDB, despite not being part of PHP anymore? Should all new
> extensions be written with a PHP namespace to account for the
> possibility of the extension being bundled with PHP at a later point
>  in time (even if there are no concrete plans to do so)?
>
> I would answer No to these questions. The namespace MongoDB is not,
> as you say, "random", it is *meaningful*. The namespace PHP is (with
>  the exceptions in the first paragraph notwithstanding) meaningless
> and an artifact of the distribution mechanism, a mechanism which may
>  change over time.

cheers
Dan
Ack

Fleshgrinder

9 years ago

On 6/11/2017 1:08 AM, Dan Ackroyd wrote:

> Hi 'Fleshgrinder',
>
> I object to this RFC on principle.
>
> RFC's are supposed to be opionated. They are supposed to present an
> argument for why we should do something, and why doing that is a good
> idea.
>
> This RFC does not do that; it presents a series of questions to vote
> on, without any clear presentation of what problem they are solving or
> why people should be vote for the RFC.
>
> Asking people to vote on things like this, leads to choice being made
> at random, when there may not even be a need to make a choice in the
> first place.
>

> Introduce namespaces to user-level symbols to avoid collisions with
> user defined symbols, decrease breaking changes due to the
> introduction of new symbols and thus increase future compatibility.

On 6/11/2017 1:08 AM, Dan Ackroyd wrote:

> These parts of the RFC are particularly lacking justification:
>> Allow plural nouns in namespaces? Yes/No
>> Use namespace for the language itself (in the future)? Yes/No
>> Name of the language namespace? core/lang
>> Use namespace for tiny self-encapsulated things (in the future)? Yes/No
>> Name of that namespace? std/util
>
> In addition, there are problems with other parts of the RFC.
>

> An important question to answer, if namespaces are to be used by PHP,
> is how they should be written. PHP has a long history of
> inconsistency, it therefore makes sense to define this upfront to
> ensure that any future effort is not going to introduce new
> inconsistencies.

> The vendor namespace itself does not contain any code directly, but
> instead is split into multiple sub-namespaces. This should ensure that
> we are not creating a new global namespace where everything that
> cannot be categorized ends up in.

> Std or util — for tiny self-contained types (e.g.
> InvalidArgumentException) and functionality where it would be total
> overkill to create a dedicated namespace for (e.g. UUID).

On 6/11/2017 1:08 AM, Dan Ackroyd wrote:

>> Coding Standard? snake_case/PascalCase
> Shouldn't this be part of the other RFC?
>

> There are two possible choices:
>
> 1. snake_case
> 2. PascalCase (in accordance with class naming)
>
> Arguments for both approaches exist, however, it is after all a purely
> cosmetic question:

On 6/11/2017 1:08 AM, Dan Ackroyd wrote:

>> This could help to avoid those 1,000+ LOC files
> Splitting files to only contain related things is a good idea.
> Splitting related things into separate files, just because some
> arbitrary line limit has been reached, is not.
>

Splitting files to related things is exactly what this RFC is about.
Nowhere does it state that files must be split by a line limit.

On 6/11/2017 1:08 AM, Dan Ackroyd wrote:

>
> From the RFC:
>> Introduce namespaces to user-level symbols to avoid collisions with user defined symbols
>>
>> Use namespace for the language itself (in the future)? Yes/No
>>
>
> From email, Fleshgrinder wrote:
>> I personally do not like this approach. PHP is the vendor of these
>> things, thus, it should reside in the namespace of the vendor. Same
>> rules for everyone.
>
> If this is actually problem, a better solution might be just reserve
> the global namespace in addition to the 'PHP' namespace. However the
> RFC does not say why it is a problem that needs addressing, and so we
> cannot explore possible solutions.
>

> Introduce namespaces to user-level symbols to avoid collisions with
> user defined symbols, decrease breaking changes due to the
> introduction of new symbols and thus increase future compatibility.

Reserving the global namespace now cannot achieve this, because it is
already in use by millions of projects out there.

On 6/11/2017 1:08 AM, Dan Ackroyd wrote:

> Multiple people have given you feedback that your idea of using a top
> level 'PHP' vendor namespace isn't a good match for the project.
> Rather than rephrasing what they have already said, I will just remind
> you of an earlier reply:
>
> From http://news.php.net/php.internals/98225
> On 2/6/2017 9:47 PM, Nikita Popov wrote:
>>
>> I'm strongly against use of the PHP namespace as a blanket namespace
>> for bundled PHP extensions. The PHP namespace should be used only
>> for functionality that is actually in some way related to PHP. For
>> example, the php-ast extension could reasonably be namespaced as
>> php\ast, as it provides an AST for PHP specifically. Similarly the
>> tokenizer extension could reasonably be namespaced as php\tokenizer.
>>
>> Extensions which are not of this type should not live in the PHP
>> namespace, because they don't have anything specifically to do with
>> php, apart from the circumstance that they happen to be bundled at
>> the current point in time. Remember that extension may move from
>> being bundled to being in PECL and vice versa. If we decide to bundle
>> the MongoDB extension with php, would we rename the currently used
>> MongoDB namespace to PHP\MongoDB? If we decided to move it back to
>> PECL, would the namespace go back to just MongoDB? Or would it stay
>> PHP\MongoDB, despite not being part of PHP anymore? Should all new
>> extensions be written with a PHP namespace to account for the
>> possibility of the extension being bundled with PHP at a later point
>>  in time (even if there are no concrete plans to do so)?
>>
>> I would answer No to these questions. The namespace MongoDB is not,
>> as you say, "random", it is *meaningful*. The namespace PHP is (with
>>  the exceptions in the first paragraph notwithstanding) meaningless
>> and an artifact of the distribution mechanism, a mechanism which may
>>  change over time.
>
> cheers
> Dan
> Ack
>

> Extensions which are provided by third-party vendors to the PHP Group
> for future maintenance and inclusion in the PHP repository go into
> their own vendor namespace. This should ensure that we can move those
> extensions to PECL without breaking compatibility on a namespace
> level.

--
Richard "Fleshgrinder" Fussenegger

Fleshgrinder

9 years ago

On 6/3/2017 6:40 PM, Fleshgrinder wrote:

> Next promised RFC (and the last one for this weekend):
>
> https://wiki.php.net/rfc/namespaces-in-core
>
> I am unsure about whether we should avoid the usage of abbreviations for
> things like language (lang), standard (std), and utility (util). I think
> it is not necessary to write them out fully, but, well, ...?!?
>

Bump! Voting could start tomorrow, but I would like to wait for the
outcome of the class naming [1] RFC and update this one before going to
vote. I also believe that there is actually still the need for further
discussion here.

@Nikita you are always quoted in this context. I would love to hear your
feedback on the RFC. I still believe that I addressed your concerns, and
actually agree with you. I hope that you understand the examples as,
well, examples.

@All I would still love some feedback on the open issues. I would also
be happy if you have ideas how the RFC could be made clearer. I know
that many want to see namespaces in core, this is a chance. Otherwise we
need to wait at least six months before a new proposal can be voted on
(see rule).

[1] https://wiki.php.net/rfc/class-naming

--
Richard "Fleshgrinder" Fussenegger

Fleshgrinder

9 years ago

On 6/3/2017 6:40 PM, Fleshgrinder wrote:

> Next promised RFC (and the last one for this weekend):
>
> https://wiki.php.net/rfc/namespaces-in-core
>
> I am unsure about whether we should avoid the usage of abbreviations for
> things like language (lang), standard (std), and utility (util). I think
> it is not necessary to write them out fully, but, well, ...?!?
>

I am withdrawing this RFC. The topic is to controversial and I do not
plan on pursuing it any further.

--
Richard "Fleshgrinder" Fussenegger