Re: [PHP-DEV] [RFC] Namespaced in bundled extensions

[Nikita Popov]

On Wed, Apr 14, 2021 at 5:39 PM Larry Garfield 
wrote:

> On Wed, Apr 14, 2021, at 9:52 AM, Nikita Popov wrote:
>
> > >> > All symbols defined in the extension should be part of the top-level
> > >> namespace or a sub-namespace.
> > >>
> > >> This should be clarified - do you mean **the extension's** top-level
> > >> namespace (e.g. OpenSSL) instead of the global namespace? I assume the
> > >> former.
> > >>
> > >
> > > Indeed, that's what I meant. I've added the extra word.
> > >
> > > Regards,
> > > Nikita
> > >
> >
> > I've now added an explicit section regarding namespace collisions to the
> > RFC, and tweaked some of the examples (String\contains, Array\contains).
> >
> > If there's no further feedback I'll open voting soon.
> >
> > Regards,
> > Nikita
>
> Thanks, Nikita.
>
> Only one remaining question/comment/request from my end: In the "Migration
> of existing symbols" section, can you clarify explicitly that this RFC does
> not preclude such migration proposals in the future?  The reading of the
> previous section could easily be taken in the future to mean "and existing
> code is stuck where it is forever", even if that's not the intent.
>
> Eg, it's fine that the RFC does not propose mass-migrating all str_*
> functions to Str\*, but if someone in the future proposes doing that
> migration (with shims/aliases), that should be able to stand on its own
> merits.  I want to preempt anyone trying to respond in such a discussion
> "the original RFC said they wouldn't move, so you can't do this migration
> RFC now," because I'm sure someone will try to use that angle in the future
> should such a proposal appear. :-)
>

Yeah, I definitely didn't want to imply that such a migration can't happen
in the future. I've now moved this into a "Future Scope" section (
https://wiki.php.net/rfc/namespaces_in_bundled_extensions#future_scope).
Hopefully that makes it clear that a followup RFC can deal with this
question.

Regards,
Nikita

Re: [PHP-DEV] [RFC] Namespaced in bundled extensions

[Larry Garfield]

On Wed, Apr 14, 2021, at 9:52 AM, Nikita Popov wrote:

> >> > All symbols defined in the extension should be part of the top-level
> >> namespace or a sub-namespace.
> >>
> >> This should be clarified - do you mean **the extension's** top-level
> >> namespace (e.g. OpenSSL) instead of the global namespace? I assume the
> >> former.
> >>
> >
> > Indeed, that's what I meant. I've added the extra word.
> >
> > Regards,
> > Nikita
> >
> 
> I've now added an explicit section regarding namespace collisions to the
> RFC, and tweaked some of the examples (String\contains, Array\contains).
> 
> If there's no further feedback I'll open voting soon.
> 
> Regards,
> Nikita

Thanks, Nikita.

Only one remaining question/comment/request from my end: In the "Migration of 
existing symbols" section, can you clarify explicitly that this RFC does not 
preclude such migration proposals in the future?  The reading of the previous 
section could easily be taken in the future to mean "and existing code is stuck 
where it is forever", even if that's not the intent.

Eg, it's fine that the RFC does not propose mass-migrating all str_* functions 
to Str\*, but if someone in the future proposes doing that migration (with 
shims/aliases), that should be able to stand on its own merits.  I want to 
preempt anyone trying to respond in such a discussion "the original RFC said 
they wouldn't move, so you can't do this migration RFC now," because I'm sure 
someone will try to use that angle in the future should such a proposal appear. 
:-)

Thanks again.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Namespaced in bundled extensions

[Nikita Popov]

On Wed, Apr 14, 2021 at 4:18 PM Nikita Popov  wrote:

> On Mon, Apr 5, 2021 at 8:05 PM tyson andre 
> wrote:
>
>> > > The question of namespaces in the stdlib has been coming up a lot
>> recently,
>> > > so I'd like to present my own stab at resolving this question:
>> > >
>> > > https://wiki.php.net/rfc/namespaces_in_bundled_extensions
>> > >
>> > > Relative to a number of previous (declined) proposals, the main
>> difference
>> > > is that I do not propose a top-level "PHP\" vendor namespace, and
>> instead
>> > > recommend the use of "ExtName\", in line with existing practice for
>> > > extensions. I believe this addresses the primary concern with previous
>> > > proposals.
>> >
>> > Both of the namespacing RFCs have been announced for over 3 weeks and I
>> don't think I've
>> > seen any new discussion since then.
>> > Are any updates planned? When will voting on the namespacing RFC(s)
>> start?
>> > (I had some stdlib RFCs/RFC ideas I was postponing since February to
>> avoid interfering with the namespacing discussion)
>> >
>> > I'd love to have some more feedback on this RFC before opening voting.
>> There has been a lot of discussion beforehand, but only a couple responses
>> to this RFC...
>>
>> I didn't plan to suggest changing the direction of the RFC, so I didn't
>> have much to say.
>> I guess it's an improvement from a user perspective and that splitting
>> core/PECL/composer namespacing wouldn't make much sense,
>> especially with the ability to polyfill most core functionality in
>> composer packages (especially with PHP providing FFI, low level
>> socket/stream code, etc).
>>
>> For something like https://wiki.php.net/rfc/cachediterable I'd still be
>> faced with the namespacing choice among multiple options if this passed,
>> but choosing names for everything is out of the scope of this RFC.
>>
>> - `iterable\CachedIterable` would be the most likely, although it's also
>> in some ways a datastructure
>> - For SPL, e.g. for a new Map type or existing classes such as
>> SplObjectStorage,
>>   there'd still be a number of different names such as
>> `DataStructure\Map` or `Collections\Map` (DS is already used by an
>> independent PECL)
>> - "When adding new symbols to existing extensions, it is more important
>> to be consistent with existing symbols than to follow the namespacing
>> guidelines."
>>   raises the question of whether existing iterables should be aliased to
>> a namespace around the same time
>> - 5 years from now we may have a different group of active voters, so if
>> this passed with low voting turnout
>>   I'm not sure if there'd still be arguments over the choice to use/not
>> use a namespace.
>>
>
> Right. I think the two main things this RFC establishes is that a) yes, it
> *is* okay to use a namespace and b) that namespace should not have a PHP\
> prefix. That still leaves you with quite a lot of different choices, but I
> think it removes the two most contentious issues from further discussion.
>
>
>> For a future iteration of https://wiki.php.net/rfc/any_all_on_iterable
>> it'd help if there was known community consensus (i.e. the vote on
>> namespaces in bundled extensions finished)
>>
>> I didn't notice before, but I assume you'd still planned to summarize
>> feedback so far in a discussion section before opening
>> https://wiki.php.net/rfc/namespaces_in_bundled_extensions
>>
>> For
>> https://wiki.php.net/rfc/namespaces_in_bundled_extensions#core_standard_spl
>> `use Array;` and `use String;` are currently syntax errors for the
>> unexpected token "array".
>> That could be fixed in the parser by adding a special case for namespace
>> uses,
>> especially now that T_NAMESPACED_NAME now allows `string\contains` to be
>> used without a syntax error.
>>
>
> Yes, those particular examples are somewhat problematic. I believe my
> original version of https://wiki.php.net/rfc/namespaced_names_as_token
> also allowed those "use" statements, so this isn't a technical problem for
> a new PHP version that decides to use them. It would be a problem for
> polyfills though, which is why we'd probably want to go for some other
> naming here. Say Str\contains instead of String\contains. (Worth noting
> that this issue also exists with "PHP\Array" before PHP 8.0, so it's not a
> problem that presence of a vendor prefix would resolve, outside specific
> cases.)
>
>
>> One possible concern is what would happen if PHP implemented new
>> functionality that overlapped with a fairly well-known PECL/Composer
>> package.
>> E.g. if there was already a FooDB\Client in a composer/PECL package, and
>> an independent implementation was later added to php-src,
>> there'd potentially be conflicting names.
>> Being able to implement `PHP\FooDB\Client` would avoid that ambiguity
>>
>> - Then again, other programming languages such as Python have no issue
>> with that, so never mind.
>>   FooDBClient\ or Foo\ or something could probably be used.
>>
>
> Right. For an existing PECL extension it would be 

Re: [PHP-DEV] [RFC] Namespaced in bundled extensions

[Nikita Popov]

On Mon, Apr 5, 2021 at 8:05 PM tyson andre 
wrote:

> > > The question of namespaces in the stdlib has been coming up a lot
> recently,
> > > so I'd like to present my own stab at resolving this question:
> > >
> > > https://wiki.php.net/rfc/namespaces_in_bundled_extensions
> > >
> > > Relative to a number of previous (declined) proposals, the main
> difference
> > > is that I do not propose a top-level "PHP\" vendor namespace, and
> instead
> > > recommend the use of "ExtName\", in line with existing practice for
> > > extensions. I believe this addresses the primary concern with previous
> > > proposals.
> >
> > Both of the namespacing RFCs have been announced for over 3 weeks and I
> don't think I've
> > seen any new discussion since then.
> > Are any updates planned? When will voting on the namespacing RFC(s)
> start?
> > (I had some stdlib RFCs/RFC ideas I was postponing since February to
> avoid interfering with the namespacing discussion)
> >
> > I'd love to have some more feedback on this RFC before opening voting.
> There has been a lot of discussion beforehand, but only a couple responses
> to this RFC...
>
> I didn't plan to suggest changing the direction of the RFC, so I didn't
> have much to say.
> I guess it's an improvement from a user perspective and that splitting
> core/PECL/composer namespacing wouldn't make much sense,
> especially with the ability to polyfill most core functionality in
> composer packages (especially with PHP providing FFI, low level
> socket/stream code, etc).
>
> For something like https://wiki.php.net/rfc/cachediterable I'd still be
> faced with the namespacing choice among multiple options if this passed,
> but choosing names for everything is out of the scope of this RFC.
>
> - `iterable\CachedIterable` would be the most likely, although it's also
> in some ways a datastructure
> - For SPL, e.g. for a new Map type or existing classes such as
> SplObjectStorage,
>   there'd still be a number of different names such as `DataStructure\Map`
> or `Collections\Map` (DS is already used by an independent PECL)
> - "When adding new symbols to existing extensions, it is more important to
> be consistent with existing symbols than to follow the namespacing
> guidelines."
>   raises the question of whether existing iterables should be aliased to a
> namespace around the same time
> - 5 years from now we may have a different group of active voters, so if
> this passed with low voting turnout
>   I'm not sure if there'd still be arguments over the choice to use/not
> use a namespace.
>

Right. I think the two main things this RFC establishes is that a) yes, it
*is* okay to use a namespace and b) that namespace should not have a PHP\
prefix. That still leaves you with quite a lot of different choices, but I
think it removes the two most contentious issues from further discussion.


> For a future iteration of https://wiki.php.net/rfc/any_all_on_iterable
> it'd help if there was known community consensus (i.e. the vote on
> namespaces in bundled extensions finished)
>
> I didn't notice before, but I assume you'd still planned to summarize
> feedback so far in a discussion section before opening
> https://wiki.php.net/rfc/namespaces_in_bundled_extensions
>
> For
> https://wiki.php.net/rfc/namespaces_in_bundled_extensions#core_standard_spl
> `use Array;` and `use String;` are currently syntax errors for the
> unexpected token "array".
> That could be fixed in the parser by adding a special case for namespace
> uses,
> especially now that T_NAMESPACED_NAME now allows `string\contains` to be
> used without a syntax error.
>

Yes, those particular examples are somewhat problematic. I believe my
original version of https://wiki.php.net/rfc/namespaced_names_as_token also
allowed those "use" statements, so this isn't a technical problem for a new
PHP version that decides to use them. It would be a problem for polyfills
though, which is why we'd probably want to go for some other naming here.
Say Str\contains instead of String\contains. (Worth noting that this issue
also exists with "PHP\Array" before PHP 8.0, so it's not a problem that
presence of a vendor prefix would resolve, outside specific cases.)


> One possible concern is what would happen if PHP implemented new
> functionality that overlapped with a fairly well-known PECL/Composer
> package.
> E.g. if there was already a FooDB\Client in a composer/PECL package, and
> an independent implementation was later added to php-src,
> there'd potentially be conflicting names.
> Being able to implement `PHP\FooDB\Client` would avoid that ambiguity
>
> - Then again, other programming languages such as Python have no issue
> with that, so never mind.
>   FooDBClient\ or Foo\ or something could probably be used.
>

Right. For an existing PECL extension it would be best to just bundle it
instead of implementing a new one (even though that seems to be in fashion
recently...) But for the more general question, we should try to be
courteous and 

Re: [PHP-DEV] [RFC] Namespaced in bundled extensions

[tyson andre]

> > The question of namespaces in the stdlib has been coming up a lot recently,
> > so I'd like to present my own stab at resolving this question:
> >
> > https://wiki.php.net/rfc/namespaces_in_bundled_extensions
> >
> > Relative to a number of previous (declined) proposals, the main difference
> > is that I do not propose a top-level "PHP\" vendor namespace, and instead
> > recommend the use of "ExtName\", in line with existing practice for
> > extensions. I believe this addresses the primary concern with previous
> > proposals.
> 
> Both of the namespacing RFCs have been announced for over 3 weeks and I don't 
> think I've
> seen any new discussion since then.
> Are any updates planned? When will voting on the namespacing RFC(s) start?
> (I had some stdlib RFCs/RFC ideas I was postponing since February to avoid 
> interfering with the namespacing discussion)
> 
> I'd love to have some more feedback on this RFC before opening voting. There 
> has been a lot of discussion beforehand, but only a couple responses to this 
> RFC...

I didn't plan to suggest changing the direction of the RFC, so I didn't have 
much to say.
I guess it's an improvement from a user perspective and that splitting 
core/PECL/composer namespacing wouldn't make much sense,
especially with the ability to polyfill most core functionality in composer 
packages (especially with PHP providing FFI, low level socket/stream code, etc).

For something like https://wiki.php.net/rfc/cachediterable I'd still be faced 
with the namespacing choice among multiple options if this passed,
but choosing names for everything is out of the scope of this RFC.

- `iterable\CachedIterable` would be the most likely, although it's also in 
some ways a datastructure
- For SPL, e.g. for a new Map type or existing classes such as 
SplObjectStorage, 
  there'd still be a number of different names such as `DataStructure\Map` or 
`Collections\Map` (DS is already used by an independent PECL)
- "When adding new symbols to existing extensions, it is more important to be 
consistent with existing symbols than to follow the namespacing guidelines."
  raises the question of whether existing iterables should be aliased to a 
namespace around the same time
- 5 years from now we may have a different group of active voters, so if this 
passed with low voting turnout
  I'm not sure if there'd still be arguments over the choice to use/not use a 
namespace.

For a future iteration of https://wiki.php.net/rfc/any_all_on_iterable it'd 
help if there was known community consensus (i.e. the vote on namespaces in 
bundled extensions finished)

I didn't notice before, but I assume you'd still planned to summarize feedback 
so far in a discussion section before opening 
https://wiki.php.net/rfc/namespaces_in_bundled_extensions

For https://wiki.php.net/rfc/namespaces_in_bundled_extensions#core_standard_spl
`use Array;` and `use String;` are currently syntax errors for the unexpected 
token "array".
That could be fixed in the parser by adding a special case for namespace uses,
especially now that T_NAMESPACED_NAME now allows `string\contains` to be used 
without a syntax error.

One possible concern is what would happen if PHP implemented new functionality 
that overlapped with a fairly well-known PECL/Composer package.
E.g. if there was already a FooDB\Client in a composer/PECL package, and an 
independent implementation was later added to php-src,
there'd potentially be conflicting names.
Being able to implement `PHP\FooDB\Client` would avoid that ambiguity

- Then again, other programming languages such as Python have no issue with 
that, so never mind.
  FooDBClient\ or Foo\ or something could probably be used.

> All symbols defined in the extension should be part of the top-level 
> namespace or a sub-namespace.

This should be clarified - do you mean **the extension's** top-level namespace 
(e.g. OpenSSL) instead of the global namespace? I assume the former.

Regards,
Tyson

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Namespaced in bundled extensions

[Mike Schinkel]

> On Mar 22, 2021, at 5:45 AM, Nikita Popov  wrote:
> 
> On Fri, Mar 19, 2021 at 7:28 PM Mike Schinkel  > wrote:
> > On Feb 25, 2021, at 3:26 PM, Nikita Popov  > > wrote:
> > 
> > Hi internals,
> > 
> > The question of namespaces in the stdlib has been coming up a lot recently,
> > so I'd like to present my own stab at resolving this question:
> > 
> > https://wiki.php.net/rfc/namespaces_in_bundled_extensions 
> > 
> > 
> > Relative to a number of previous (declined) proposals, the main difference
> > is that I do not propose a top-level "PHP\" vendor namespace, and instead
> > recommend the use of "ExtName\", in line with existing practice for
> > extensions. I believe this addresses the primary concern with previous
> > proposals.
> 
> Hi Nikita,
> 
> Can I request/suggest that if we are going to take this approach that the RFC 
> also adds an "advisory" registry for namespaces in the form of a Github repo 
> with parallel README.md and namespaces.json files containing "registered" 
> namespaces and a link for more information?
> 
> The benefit of such a registry would be to allow people who want to avoid 
> using a namespace others are already using in public to find the list of 
> namespaces for code that has been published publicly. Full stop.
> 
> For what I am proposing, the registry would NOT be used to _stop_ people from 
> using "registered" namespaces. They would be free to do so if they chose to. 
> The registry would instead be for those who want to ensure their code is most 
> likely to play nice with anyone else's code.
> 
> The registration process would be as simple as submitting a PR that includes 
> the requested namespace added to both the README.md and the namespaces.json 
> file along with a link for more information.
> 
> There would not be any approval process per se other than merging the PR, and 
> there would not be any "owner" of the registration per se as registration 
> would merely be a stake in the ground to recommend others not use that same 
> namespace. 
> 
> I'd suggest registration of really generic namespaces would be discouraged, 
> but not disallowed.
> 
> I envision the link to more information would be a link to a git repo with 
> either the code or information about the namespace in the README.  If after a 
> namespace is registered we find that other people/organizations are using the 
> same namespace then the maintainers of the repo could choose to add multiple 
> links to the same namespace.
> 
> Again, in summary, this list of "registrations" would be to allow people to 
> easily find out if the namespace they want to use has already been used 
> publicly by others, and if not to allow them to "register" it for their use.
> 
> If maintainers of the repo discover and PR behavior that is suspect, they 
> could bring to the internals list to discuss a resolution. But unless and 
> until that happens, governance of this registry would be as minimal as 
> possible.
> 
> Is this something you can/will add to your RFC?
> 
> -Mike
> P.S. If this existed it would be something PhpStorm (and VSCode) could 
> probably use to help developers who find namespaces in code to be able to 
> find out where they can learn more about those namespaces.  And later, the 
> git repo could publish a namespace.json with a lot more information about the 
> namespace that could help PhpStorm offer even more help to developers.  
> #justsaying
> 
> No, I am not willing to add a namespace registry to the RFC.
> 
> I do acknowledge that the lack of vendor prefix may make namespace collisions 
> more likely, although an important mitigating factor here is that that 
> userland libraries (unlike existing extensions) do typically use a vendor 
> namespace, and vendor namespaces usually do not collide with component 
> namespaces.

I appreciate and respect your decision.

> I also think that there should be some common courtesy involved in the choice 
> of namespaces -- if there is some really popular unvendored open-source 
> library out there that already uses some namespace prefix, we definitely 
> should consider that in our naming decisions.
> 
> But I don't think this needs any formal process of namespace registration, 
> which creates unnecessary bureaucracy and misaligned expectations. If your 
> library is important enough, then people will be aware of the issue. The 
> converse also holds.

But I do want to point out it can be difficult to discover namespaces that may 
conflict when they are not the main namespace for a popular open-source 
solution. So it sucks for the developer who wants to use two conflicting "not 
important enough" libraries.

But I do accept that this idea is a no-go in your RFC.

-Mike

Re: [PHP-DEV] [RFC] Namespaced in bundled extensions

[Nikita Popov]

On Fri, Mar 19, 2021 at 7:28 PM Mike Schinkel  wrote:

> > On Feb 25, 2021, at 3:26 PM, Nikita Popov  wrote:
> >
> > Hi internals,
> >
> > The question of namespaces in the stdlib has been coming up a lot
> recently,
> > so I'd like to present my own stab at resolving this question:
> >
> > https://wiki.php.net/rfc/namespaces_in_bundled_extensions
> >
> > Relative to a number of previous (declined) proposals, the main
> difference
> > is that I do not propose a top-level "PHP\" vendor namespace, and instead
> > recommend the use of "ExtName\", in line with existing practice for
> > extensions. I believe this addresses the primary concern with previous
> > proposals.
>
> Hi Nikita,
>
> Can I request/suggest that if we are going to take this approach that the
> RFC also adds an "advisory" registry for namespaces in the form of a Github
> repo with parallel README.md and namespaces.json files containing
> "registered" namespaces and a link for more information?
>
> The benefit of such a registry would be to allow people who want to avoid
> using a namespace others are already using in public to find the list of
> namespaces for code that has been published publicly. Full stop.
>
> For what I am proposing, the registry would NOT be used to _stop_ people
> from using "registered" namespaces. They would be free to do so if they
> chose to. The registry would instead be for those who want to ensure their
> code is most likely to play nice with anyone else's code.
>
> The registration process would be as simple as submitting a PR that
> includes the requested namespace added to both the README.md and the
> namespaces.json file along with a link for more information.
>
> There would not be any approval process per se other than merging the PR,
> and there would not be any "owner" of the registration per se as
> registration would merely be a stake in the ground to recommend others not
> use that same namespace.
>
> I'd suggest registration of really generic namespaces would be
> discouraged, but not disallowed.
>
> I envision the link to more information would be a link to a git repo with
> either the code or information about the namespace in the README.  If after
> a namespace is registered we find that other people/organizations are using
> the same namespace then the maintainers of the repo could choose to add
> multiple links to the same namespace.
>
> Again, in summary, this list of "registrations" would be to allow people
> to easily find out if the namespace they want to use has already been used
> publicly by others, and if not to allow them to "register" it for their use.
>
> If maintainers of the repo discover and PR behavior that is suspect, they
> could bring to the internals list to discuss a resolution. But unless and
> until that happens, governance of this registry would be as minimal as
> possible.
>
> Is this something you can/will add to your RFC?
>
> -Mike
> P.S. If this existed it would be something PhpStorm (and VSCode) could
> probably use to help developers who find namespaces in code to be able to
> find out where they can learn more about those namespaces.  And later, the
> git repo could publish a namespace.json with a lot more information about
> the namespace that could help PhpStorm offer even more help to developers.
> #justsaying
>

No, I am not willing to add a namespace registry to the RFC.

I do acknowledge that the lack of vendor prefix may make namespace
collisions more likely, although an important mitigating factor here is
that that userland libraries (unlike existing extensions) do typically use
a vendor namespace, and vendor namespaces usually do not collide with
component namespaces.

I also think that there should be some common courtesy involved in the
choice of namespaces -- if there is some really popular unvendored
open-source library out there that already uses some namespace prefix, we
definitely should consider that in our naming decisions. But I don't think
this needs any formal process of namespace registration, which creates
unnecessary bureaucracy and misaligned expectations. If your library is
important enough, then people will be aware of the issue. The converse also
holds.

Regards,
Nikita

Re: [PHP-DEV] [RFC] Namespaced in bundled extensions

[Mike Schinkel]

> On Mar 19, 2021, at 2:44 PM, Christoph M. Becker  wrote:
> 
> On 19.03.2021 at 19:28, Mike Schinkel wrote:
> 
>> The registration process would be as simple as submitting a PR that includes 
>> the requested namespace added to both the README.md and the namespaces.json 
>> file along with a link for more information.
>> 
>> There would not be any approval process per se other than merging the PR, 
>> and there would not be any "owner" of the registration per se as 
>> registration would merely be a stake in the ground to recommend others not 
>> use that same namespace.
> 
> I wonder how long it would take for somebody to submit a PR which
> registers several millions of arbitrary namespaces.

A good bit longer than it would take to deny the PR and not merge it, I'm sure.

So I guess to be explicit, one namespace per PR.

-Mike

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Namespaced in bundled extensions

[Christoph M. Becker]

On 19.03.2021 at 19:28, Mike Schinkel wrote:

> The registration process would be as simple as submitting a PR that includes 
> the requested namespace added to both the README.md and the namespaces.json 
> file along with a link for more information.
>
> There would not be any approval process per se other than merging the PR, and 
> there would not be any "owner" of the registration per se as registration 
> would merely be a stake in the ground to recommend others not use that same 
> namespace.

I wonder how long it would take for somebody to submit a PR which
registers several millions of arbitrary namespaces.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Namespaced in bundled extensions

[Mike Schinkel]

> On Feb 25, 2021, at 3:26 PM, Nikita Popov  wrote:
> 
> Hi internals,
> 
> The question of namespaces in the stdlib has been coming up a lot recently,
> so I'd like to present my own stab at resolving this question:
> 
> https://wiki.php.net/rfc/namespaces_in_bundled_extensions
> 
> Relative to a number of previous (declined) proposals, the main difference
> is that I do not propose a top-level "PHP\" vendor namespace, and instead
> recommend the use of "ExtName\", in line with existing practice for
> extensions. I believe this addresses the primary concern with previous
> proposals.

Hi Nikita,

Can I request/suggest that if we are going to take this approach that the RFC 
also adds an "advisory" registry for namespaces in the form of a Github repo 
with parallel README.md and namespaces.json files containing "registered" 
namespaces and a link for more information?

The benefit of such a registry would be to allow people who want to avoid using 
a namespace others are already using in public to find the list of namespaces 
for code that has been published publicly. Full stop.

For what I am proposing, the registry would NOT be used to _stop_ people from 
using "registered" namespaces. They would be free to do so if they chose to. 
The registry would instead be for those who want to ensure their code is most 
likely to play nice with anyone else's code.

The registration process would be as simple as submitting a PR that includes 
the requested namespace added to both the README.md and the namespaces.json 
file along with a link for more information.

There would not be any approval process per se other than merging the PR, and 
there would not be any "owner" of the registration per se as registration would 
merely be a stake in the ground to recommend others not use that same 
namespace. 

I'd suggest registration of really generic namespaces would be discouraged, but 
not disallowed.

I envision the link to more information would be a link to a git repo with 
either the code or information about the namespace in the README.  If after a 
namespace is registered we find that other people/organizations are using the 
same namespace then the maintainers of the repo could choose to add multiple 
links to the same namespace.

Again, in summary, this list of "registrations" would be to allow people to 
easily find out if the namespace they want to use has already been used 
publicly by others, and if not to allow them to "register" it for their use.

If maintainers of the repo discover and PR behavior that is suspect, they could 
bring to the internals list to discuss a resolution. But unless and until that 
happens, governance of this registry would be as minimal as possible.

Is this something you can/will add to your RFC?

-Mike
P.S. If this existed it would be something PhpStorm (and VSCode) could probably 
use to help developers who find namespaces in code to be able to find out where 
they can learn more about those namespaces.  And later, the git repo could 
publish a namespace.json with a lot more information about the namespace that 
could help PhpStorm offer even more help to developers.  #justsaying

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Namespaced in bundled extensions

[Christoph M. Becker]

On 19.03.2021 at 15:13, Nikita Popov wrote:

> I'd love to have some more feedback on this RFC before opening voting.
> There has been a lot of discussion beforehand, but only a couple responses
> to this RFC...

I very much like this pragmatic approach, which also matches most of the
already existing extensions using namespaces.  Thank you!

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Namespaced in bundled extensions

[G. P. B.]

On Thu, 25 Feb 2021 at 20:26, Nikita Popov  wrote:

> Hi internals,
>
> The question of namespaces in the stdlib has been coming up a lot recently,
> so I'd like to present my own stab at resolving this question:
>
> https://wiki.php.net/rfc/namespaces_in_bundled_extensions
>
> Relative to a number of previous (declined) proposals, the main difference
> is that I do not propose a top-level "PHP\" vendor namespace, and instead
> recommend the use of "ExtName\", in line with existing practice for
> extensions. I believe this addresses the primary concern with previous
> proposals.
>
> Regards,
> Nikita
>

As one of the co-authors of one of the previously declined RFCs [1] and
author of the CSV extension, [2] where I changed from using prefixed
functions to a global class called CSV in the same fashion as FFI,
I quite like this proposal, and have no issue changing it to conform to
the RFC.

This sidesteps the issue of the PHP namespace in a very elegant way
by not creating a weird dichotomy for "core" (core/standard/SPL) functions,
if some of them start using namespaces as they'll only be one level deep
and the name is relevant to the functionality they provide.

Best regards,

George P. Banyard

[1] https://wiki.php.net/rfc/php-namespace-in-core
[2]
https://gitlab.com/Girgias/csv-php-extension/-/commit/dc48b449543b07eaeff575bd143350693f808d74

Re: [PHP-DEV] [RFC] Namespaced in bundled extensions

[Nikita Popov]

On Fri, Mar 19, 2021 at 3:04 PM tyson andre 
wrote:

> Hi Nikita Popov,
>
> > The question of namespaces in the stdlib has been coming up a lot
> recently,
> > so I'd like to present my own stab at resolving this question:
> >
> > https://wiki.php.net/rfc/namespaces_in_bundled_extensions
> >
> > Relative to a number of previous (declined) proposals, the main
> difference
> > is that I do not propose a top-level "PHP\" vendor namespace, and instead
> > recommend the use of "ExtName\", in line with existing practice for
> > extensions. I believe this addresses the primary concern with previous
> > proposals.
>
> Both of the namespacing RFCs have been announced for over 3 weeks and I
> don't think I've
> seen any new discussion since then.
> Are any updates planned? When will voting on the namespacing RFC(s) start?
> (I had some stdlib RFCs/RFC ideas I was postponing since February to avoid
> interfering with the namespacing discussion)
>

I'd love to have some more feedback on this RFC before opening voting.
There has been a lot of discussion beforehand, but only a couple responses
to this RFC...

Regards,
Nikita

Re: [PHP-DEV] [RFC] Namespaced in bundled extensions

[tyson andre]

Hi Nikita Popov,

> The question of namespaces in the stdlib has been coming up a lot recently,
> so I'd like to present my own stab at resolving this question:
>
> https://wiki.php.net/rfc/namespaces_in_bundled_extensions
>
> Relative to a number of previous (declined) proposals, the main difference
> is that I do not propose a top-level "PHP\" vendor namespace, and instead
> recommend the use of "ExtName\", in line with existing practice for
> extensions. I believe this addresses the primary concern with previous
> proposals.

Both of the namespacing RFCs have been announced for over 3 weeks and I don't 
think I've
seen any new discussion since then.
Are any updates planned? When will voting on the namespacing RFC(s) start?
(I had some stdlib RFCs/RFC ideas I was postponing since February to avoid 
interfering with the namespacing discussion)

Thanks,
Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Namespaced in bundled extensions

[Pierre]

Le 25/02/2021 à 21:26, Nikita Popov a écrit :

Hi internals,

The question of namespaces in the stdlib has been coming up a lot recently,
so I'd like to present my own stab at resolving this question:

https://wiki.php.net/rfc/namespaces_in_bundled_extensions

Relative to a number of previous (declined) proposals, the main difference
is that I do not propose a top-level "PHP\" vendor namespace, and instead
recommend the use of "ExtName\", in line with existing practice for
extensions. I believe this addresses the primary concern with previous
proposals.

Regards,
Nikita


Hello,

Thank you so much for this RFC, this is a big +1 for me.

There's only one caveat: wouldn't this create name conflicts with some 
existing third-party libraries ? Anyway, if it does, it'll conflict with 
Array, or Password, or OpenSSL named libraries, and in this case, it 
means they have voluntarily ignored the vendoring convention, which is 
evil-designed since they would take a common name as root namespaces and 
prevent legitimate use of those, and they should probably be fixed.


--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Namespaced in bundled extensions

[Benjamin Morel]

>
> Maybe off-topic, but I don't think you could "fix" them:
> for array_map, the array is variadic-like, so must be last;
> for array_filter, the callback is optional, so must be after the array.
> (Correct me if I'm wrong.)
>
> --
> Guilliam Xavier
>

Good point. Then that would be an opportunity to question whether
array_map() is doing too much, and should just work on a single array.
Like Array.map()

in JS, Stream.map()

in Java, Iterator.map()
 in
Rust, etc.

— Benjamin

Re: [PHP-DEV] [RFC] Namespaced in bundled extensions

[Guilliam Xavier]

On Fri, Feb 26, 2021 at 12:18 PM Benjamin Morel 
wrote:

> Thank you for this RFC, Nikita. This is a necessary first step in the right
> direction.
>
> Even though this is out of scope for this RFC, I hope that moving standard
> functions to namespaces will be an opportunity to fix inconsistencies in
> parameter order, like:
>
> array_map($callback, array)
> array_filter($array, $callback)
>
> and not just an alias under a namespace!
>

Maybe off-topic, but I don't think you could "fix" them:
for array_map, the array is variadic-like, so must be last;
for array_filter, the callback is optional, so must be after the array.
(Correct me if I'm wrong.)

-- 
Guilliam Xavier

Re: [PHP-DEV] [RFC] Namespaced in bundled extensions

[Benjamin Morel]

Thank you for this RFC, Nikita. This is a necessary first step in the right
direction.

Even though this is out of scope for this RFC, I hope that moving standard
functions to namespaces will be an opportunity to fix inconsistencies in
parameter order, like:

array_map($callback, array)
array_filter($array, $callback)

and not just an alias under a namespace!

 — Benjamin

On Thu, 25 Feb 2021 at 21:26, Nikita Popov  wrote:

> Hi internals,
>
> The question of namespaces in the stdlib has been coming up a lot recently,
> so I'd like to present my own stab at resolving this question:
>
> https://wiki.php.net/rfc/namespaces_in_bundled_extensions
>
> Relative to a number of previous (declined) proposals, the main difference
> is that I do not propose a top-level "PHP\" vendor namespace, and instead
> recommend the use of "ExtName\", in line with existing practice for
> extensions. I believe this addresses the primary concern with previous
> proposals.
>
> Regards,
> Nikita
>

[PHP-DEV] [RFC] Namespaced in bundled extensions

[Nikita Popov]

Hi internals,

The question of namespaces in the stdlib has been coming up a lot recently,
so I'd like to present my own stab at resolving this question:

https://wiki.php.net/rfc/namespaces_in_bundled_extensions

Relative to a number of previous (declined) proposals, the main difference
is that I do not propose a top-level "PHP\" vendor namespace, and instead
recommend the use of "ExtName\", in line with existing practice for
extensions. I believe this addresses the primary concern with previous
proposals.

Regards,
Nikita