Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On Tue, Jul 21, 2020, at 3:31 AM, Rowan Tommins wrote: > On Tue, 21 Jul 2020 at 01:36, Mark Randall wrote: > > > So either you fake namespaces e.g. PhpToken or you trample on userland > > \Tokenizer. > > > > > While you're making a reasonable point, I really wish people would stop > using that particular class as an example, because I don't think the "PHP" > in its name is a " fake namespace" at all - it is an object representing a > token of PHP source code, and thus a PHP token. Even inside a namespace, > there would be an argument for giving it that name. > > Regards, > -- > Rowan Tommins > [IMSoP] To use another, then: \AttributeDeprecated vs \PHP\Attributes\Deprecated \AttributeJIT vs \PHP\Attributes\JIT \AttributeMemoize vs \PHP\Attributes\Memoize There's a very strong potential for php-src to add a number of attribute classes, which would logically have very generic seeming names. Getting those out of the global namespace and into a logical organization would be very good. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On Tue, 21 Jul 2020 at 01:36, Mark Randall wrote: > So either you fake namespaces e.g. PhpToken or you trample on userland > \Tokenizer. > While you're making a reasonable point, I really wish people would stop using that particular class as an example, because I don't think the "PHP" in its name is a " fake namespace" at all - it is an object representing a token of PHP source code, and thus a PHP token. Even inside a namespace, there would be an argument for giving it that name. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On 20/07/2020 16:58, Michael Wallner wrote: Distilled down, I just cannot see any huge benefit out of a (or two) root namespace(s). As a project we rightfully own the root namespace, and putting everything beneath PHP just doesn't make any sense to me. You cannot just "own" the root namespace if you want to use namespaces yourself, which we will, it's inevitable, the number of classes and interfaces increases more and more each release. So either you fake namespaces e.g. PhpToken or you trample on userland \Tokenizer. There is one solution to this, and that is to have a vendor namespace for the PHP project itself, naturally the one that is reserved, \PHP. There's a very good reason modern language frameworks claim a couple of root level namespaces, e.g. .NET it's System.* and Microsoft.*, for Java it's java.* -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On Mon, 20 Jul 2020 at 16:58, Michael Wallner wrote: > Distilled down, I just cannot see any huge benefit out of a (or two) root > namespace(s). As a project we rightfully own the root namespace, and > putting everything beneath PHP just doesn't make any sense to me. > I will ask you the same question I have asked others, but without much response: would you vote Yes to an alternative proposal to officially adopt a policy of _never_ using the PHP\* namespace, to eliminate future debates about when to use it? Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
Hi Larry! Larry Garfield schrieb am Mi., 24. Juni 2020, 02:30: > Greetings, Internalians. > > *dons flame retardant suit* Thank your for your efforts, but I'm about to cast a negative vote on this policy. Distilled down, I just cannot see any huge benefit out of a (or two) root namespace(s). As a project we rightfully own the root namespace, and putting everything beneath PHP just doesn't make any sense to me. Also, most code more than a handful of files is already vendored, and if not a common idiom I see often used, is a simple 'app' or '' namespace. Closing, just let me ensure that it is not because one of my extensions accidentally provides a class beneath a 'php' namespace. Regards, Mike
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On Fri, Jul 17, 2020, at 7:20 AM, Mark Randall wrote: > On 17/07/2020 09:23, Lester Caine wrote: > > So does that also apply to \Ext? Currently the selection of extensions > > is flexible and most distributions allow the easy repackaging of just > > what is available. Creating a 'core' set off extensions under \PHP is > > essentially saying 'you will make these available' while \Ext is a > > second class citizen? Personally I think every package even if relegated > > to PECL deserves to be under \PHP or alternately ONLY the essential core > > engine components go under \PHP and everything else is \Ext > > Things under \PHP will be related to either the engine itself, universal > helpers, or PHP as a language. > > Everything else, including almost all extensions bundled with php-src, > would go under \Ext > > > > Many of the 'exotic' functions such as 'reflection' are not essential > > for writing good code, so a core \PHP which defines an essential working > > set of functions does make sense. What HAS been lost is the development > > of better extensions such as a \Ext\String or \Ext|Array extension that > > is more 'object orientated' while leaving the legacy functions wrapped > > in \PHP ... > > > > Object-orientated styles for strings / arrays provided by the engine > would still go in the root. To provide at little broader perspective: There's several places that code may live: 1. The engine 2. A required bundled extension 3. An optional/disableable bundled extension 4. A non-bundled (PECL) extension 5. User-space Code sometimes transitions from one home to another; extensions get bundled or unbundled, code is moved from engine to extension or back, user-space code is ported to an extension, etc. If there are namespaces used at all to indicate "origin" (which of the above categories it falls into), then at least one of those moves is going to also imply renaming. We could debate which one is least impactful, has the best ROI, has the easiest BC handling, etc., but at least one of those boundaries is going to be bumpier than the others. I personally don't have strong feelings about which boundary we make easier or harder; As long as there is consensus and we have a way to not dump everything in php-src randomly into the global namespace, I'm happy. :-) But any namespace usage is going to imply, well, naming things. (Just be glad we're not also trying to solve caching at the same time here...) If namespaces used by php-src do not indicate origin, then they run the sizeable risk of colliding with user-space code, which is exactly what we're trying to avoid. As far as the depth of the namespace, The three level class name (vendor/component/class.php) is already the nearly universal standard in PHP thanks to PSR-0, PSR-4, and Composer. Really all that's being done here is officially reserving and using PHP (and/or Ext) as the "core vendor," and then following existing conventions. Everything else is already the standard practice across the ecosystem, just said in more formal words with some collaboration processes defined. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On 17/07/2020 09:23, Lester Caine wrote: So does that also apply to \Ext? Currently the selection of extensions is flexible and most distributions allow the easy repackaging of just what is available. Creating a 'core' set off extensions under \PHP is essentially saying 'you will make these available' while \Ext is a second class citizen? Personally I think every package even if relegated to PECL deserves to be under \PHP or alternately ONLY the essential core engine components go under \PHP and everything else is \Ext Things under \PHP will be related to either the engine itself, universal helpers, or PHP as a language. Everything else, including almost all extensions bundled with php-src, would go under \Ext Many of the 'exotic' functions such as 'reflection' are not essential for writing good code, so a core \PHP which defines an essential working set of functions does make sense. What HAS been lost is the development of better extensions such as a \Ext\String or \Ext|Array extension that is more 'object orientated' while leaving the legacy functions wrapped in \PHP ... Object-orientated styles for strings / arrays provided by the engine would still go in the root. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On Fri, 17 Jul 2020 at 04:50, Levi Morrison via internals < internals@lists.php.net> wrote: > This is not quite the same. I said it moves from _userland_ aka PHP > code, to an _extension_ aka C code. I oppose `Ext` in both case. > Hi Levi, Given this, I presume you also oppose `PHP\` for those cases. Do you see value in using that namespace for code which could never be implemented in userland, or would you prefer a policy of never using it? Relatedly, would you be in favour of allowing bundled extensions to use namespaces in general, with no vendor prefix (as Sodium did in PECL)? Or should the policy be that there are no namespaces used by the core? Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On 16/07/2020 22:42, Larry Garfield wrote: After some discussion, the namespacing proposal has been again updated. Two major changes: 1) Only engine code goes in \PHP. There's a separate \Ext namespace for extensions, whether bundled or PECL. From RFC ... " This RFC does NOT propose moving any existing code into the \PHP namespace at this time. That may be done by future RFCs if desired, under their own votes. This is a “policy document” only. " So does that also apply to \Ext? Currently the selection of extensions is flexible and most distributions allow the easy repackaging of just what is available. Creating a 'core' set off extensions under \PHP is essentially saying 'you will make these available' while \Ext is a second class citizen? Personally I think every package even if relegated to PECL deserves to be under \PHP or alternately ONLY the essential core engine components go under \PHP and everything else is \Ext 2) It establishes that an index will be maintained on the Wiki listing what namespaces are already claimed. https://wiki.php.net/rfc/php_namespace_policy This is probably (I hope) the final edit of consequence before voting. Speak now or forever hold your peace.:-) Many of the 'exotic' functions such as 'reflection' are not essential for writing good code, so a core \PHP which defines an essential working set of functions does make sense. What HAS been lost is the development of better extensions such as a \Ext\String or \Ext|Array extension that is more 'object orientated' while leaving the legacy functions wrapped in \PHP ... -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On 17/07/2020 04:49, Levi Morrison via internals wrote: I don't care to debate it. I will just vote no. Fair enough, however the point of the internals mailing list and discussion period is to debate the RFCs :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On Thu, Jul 16, 2020 at 9:29 PM Mark Randall wrote: > > On 17/07/2020 02:58, Levi Morrison via internals wrote: > >2. I don't think this is solving any problems, really: > > - Code can move from PHP land to an extension and back again. > > Should the namespace change just because it moved one way or the > > other? I vote no. > > This is not what the RFC proposes. The point of \Ext is that there would > be no need to rename them when moving in or out of core. This is not quite the same. I said it moves from _userland_ aka PHP code, to an _extension_ aka C code. I oppose `Ext` in both case. > > I'm strongly in the "make namespace short and flat" camp. Deeply > > nested namespaces make more sense when you need to distinguish between > > projects within a company, for a contrived example > > `Amazon\WebServices\SDK`. I can see there being multiple projects with > > Amazon, and I can see there being multiple WebServices projects. > > Removing a namespace segment doesn't make a lot of sense either, > > except for perhaps collapsing the first two to `AWS` but this is just > > another point to my short and flat camp. This deeply nested company > > organization is not the territory we are in as a project, so we should > > keep it simple and keep our namespace short and simple. > > How flat would you want it to be? This RFC proposes 1 level before the > name of the feature, either PHP or Ext depending on its location. The > purpose of that one level is to avoid extensions trampling into multiple > userspace naming areas. There is no need to separate between _extensions_ and _userland_ code. I believe this very premise is flawed. I don't care to debate it. I will just vote no. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On 17/07/2020 02:58, Levi Morrison via internals wrote: 2. I don't think this is solving any problems, really: - Code can move from PHP land to an extension and back again. Should the namespace change just because it moved one way or the other? I vote no. This is not what the RFC proposes. The point of \Ext is that there would be no need to rename them when moving in or out of core. I'm strongly in the "make namespace short and flat" camp. Deeply nested namespaces make more sense when you need to distinguish between projects within a company, for a contrived example `Amazon\WebServices\SDK`. I can see there being multiple projects with Amazon, and I can see there being multiple WebServices projects. Removing a namespace segment doesn't make a lot of sense either, except for perhaps collapsing the first two to `AWS` but this is just another point to my short and flat camp. This deeply nested company organization is not the territory we are in as a project, so we should keep it simple and keep our namespace short and simple. How flat would you want it to be? This RFC proposes 1 level before the name of the feature, either PHP or Ext depending on its location. The purpose of that one level is to avoid extensions trampling into multiple userspace naming areas. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On Thu, Jul 16, 2020 at 3:42 PM Larry Garfield wrote: > > After some discussion, the namespacing proposal has been again updated. Two > major changes: > > 1) Only engine code goes in \PHP. There's a separate \Ext namespace for > extensions, whether bundled or PECL. > > 2) It establishes that an index will be maintained on the Wiki listing what > namespaces are already claimed. > > https://wiki.php.net/rfc/php_namespace_policy > > This is probably (I hope) the final edit of consequence before voting. Speak > now or forever hold your peace. :-) Chiming in to formally oppose `\Ext`. I don't think it holds much value for a few reasons: 1. If all extensions are in the same namespace then they have to work out conflicts between themselves anyway. This would not have helped mongo and mongodb, for instance, nor memcache and memcached. 2. I don't think this is solving any problems, really: - Code can move from PHP land to an extension and back again. Should the namespace change just because it moved one way or the other? I vote no. - It's more typing for... what gain, exactly? I'm strongly in the "make namespace short and flat" camp. Deeply nested namespaces make more sense when you need to distinguish between projects within a company, for a contrived example `Amazon\WebServices\SDK`. I can see there being multiple projects with Amazon, and I can see there being multiple WebServices projects. Removing a namespace segment doesn't make a lot of sense either, except for perhaps collapsing the first two to `AWS` but this is just another point to my short and flat camp. This deeply nested company organization is not the territory we are in as a project, so we should keep it simple and keep our namespace short and simple. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
After some discussion, the namespacing proposal has been again updated. Two major changes: 1) Only engine code goes in \PHP. There's a separate \Ext namespace for extensions, whether bundled or PECL. 2) It establishes that an index will be maintained on the Wiki listing what namespaces are already claimed. https://wiki.php.net/rfc/php_namespace_policy This is probably (I hope) the final edit of consequence before voting. Speak now or forever hold your peace. :-) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On 10/07/2020 09:54, Nikita Popov wrote: For me, dealing with PHP <-> PECL moves is an important part of adopting namespaces in php-src, and I don't think the current proposal addresses this issue sufficiently. (One way to address it would be to drop the PHP\ prefix, and use unvendored namespace names for php-src.) There is another option that we reserve \Ext as well (not \PHP\Ext) \PHP stays for engine level classes (core, collections etc) \PHP\Annotations\JIT \PHP\Tokenizer\Token ... \Ext gets used for extensions, including bundled extensions. Anyone with good standing can request an \Ext (or could use one without requesting it, but it wouldn't be a BC break if an officially approved extension took its name). \Ext\Mysqli\Connection \Ext\Mysqli\Result \Ext\Gd\Image \Ext\Curl\Handle ... This would also solve the long-problem of an ever-increasing number of classes and symbols placed into the root namespace. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On Thu, 9 Jul 2020 at 18:04, Larry Garfield wrote: > > I've no idea what the rules are around new version numbers > of RFCs that haven't been up for a vote yet. I pretty strongly recommend people against re-using documents. If it's going to change significantly, using a new doc makes it easier to see it's a different idea. Alternatively summarising the changes might be more appropriate for smaller changes. Larry wrote: > Which guidelines in particular bug you, and why? Just to note, my problem isn't just with the details, but to pick out a few. RFC text: > Any namespaced code provided by PHP-SRC will use a sub-namespace of \PHP. > That is, no PHP\Foo class may be defined, That seems like something that will have reasonable exceptions to. RFC text: > Classes that are part of a disable-able extension > Eg, \PHP\Sodium. I don't believe extensions should necessarily be under a PHP namespace. Instead that should be thought about case-by-case. Also, extensions can move from being one that can be disabled to not being disable-able. RFC text: > Upgrade path for existing classes > That is, a rename introduced in PHP 8.2 is not eligible to have its > old name removed until at least 10.0. The reason for having aliases is mostly to allow easier upgrading. i.e. i) User code runs on version x.y of PHP. ii) User code runs on version x.(y+1) of PHP. iii) The user changes any use of old names on x.(y+1). iv) Old names can be remove in version x.(y+2) Keeping aliases of old names around for longer than that isn't that useful. But again, this should be thought about case-by-case. Rowan Tommins wrote: > This is pure whataboutery; the idea that reading a few > naming conventions will be such a burden that somebody > would have no time to review a feature is frankly ridiculous. That's getting pretty close to just name-calling. It's fine to think that there is a problem here, and that adopting this RFC is an appropriate solution to that problem. But I think that there isn't really a problem to solve here, and that even if there is, solving it through an RFC is worse than just ignoring the problem. This difference in approach possibly comes from a difference in philosophy. aka I think we're both making sensible arguments, but based on different values of what is important, and so coming to different conclusions. I've recommended the book Systemantics before: https://en.wikipedia.org/wiki/Systemantics It has lots of very useful advice about the counter-intuitive results that emerge from decisions. And it's from that approach to systems design that I'm basing my thinking. One of the most simplest pieces of advice it gives is: "First rule of systems design: do without out one if possible" And one of the few pieces of advice that I give to people, that I'm pretty sure is right is: "Accept you're going to be wrong - Make it easier to correct mistakes." which was part of a whole talk I gave at DPC* I don't think this RFC provides much benefit now, and I don't think it makes it easier to name things in the future. In fact it makes things more difficult as any exceptions to the rules laid down in this RFC now become "DEVIATIONS FROM OUR ALREADY DECIDED RULES!!1!" rather than things that can be thought about as code, coding standards, and people's personal preferences all evolve. cheers Dan Ack * Video: https://www.youtube.com/watch?v=TS9BNa1MDW0 Slides: http://docs.basereality.com/GoodOrBad_DPC/ Apologies for the quality of my voice which made the presentation quality not as high as I had hoped. But it does lead to the 2nd piece of advice I'm pretty sure is correct, which is "wear a seatbelt so you don't damage your spine in a car crash" which might seem kind of obvious advice in retrospect. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On Fri, Jul 10, 2020, at 3:54 AM, Nikita Popov wrote:
> On Tue, Jul 7, 2020 at 4:47 PM Larry Garfield
> wrote:
>
> > On Tue, Jun 23, 2020, at 7:30 PM, Larry Garfield wrote:
> > > Greetings, Internalians.
> > >
> > > There has been much talk of the \PHP namespace of late, including one
> > > unsuccessful RFC. In the discussion, the pushback broke down into two
> > > main camps:
> > >
> > > * We should never namespace anything ever.
> > > * We can namespace things but we need something more concrete than
> > > "RFCs can namespace things if they feel like it."
> > >
> > > I can't do much about the former, but the latter is a solvable problem.
> > > To that end, Mark Randall and I have put together a new RFC on the
> > > topic, based on a fruitful discussion in Room 11 a few weeks ago to
> > > brainstorm what actual guidelines should be for what goes where.
> > >
> > > https://wiki.php.net/rfc/php_namespace_policy
> > >
> > > This proposal provides guidance to short circuit future subjective
> > > bikeshedding, while still leaving some wiggle room for case-by-case
> > > evaluation as needed. That makes it different from prior attempts that
> > > did not provide clear guidance for future RFC authors.
> > >
> > > The specific guidelines offered may or may not appeal to you; those are
> > > open to discussion (within reason; we don't want to end up back in "do
> > > whatever" land as we know that won't help), but the more important
> > > point is that clear guidelines are provided.
> > >
> > > Also of note, although it uses existing code to demonstrate where
> > > classes *would* go under this plan it does not immediately move
> > > anything. Those are left for future RFCs that would have to stand or
> > > fall on their own merit. It also provides for a very long grace period
> > > for any such transitions to minimize disruption.
> > >
> > > The intent is to bring this proposal to a vote in time for 8.0's freeze
> > > one way or another, even though it's unlikely to have any impact on 8.0
> > > itself. It's still a convenient deadline.
> > >
> > > *dons flame retardant suit*
> > >
> > > --
> > > Larry Garfield
> > > la...@garfieldtech.com
> >
> > This has reached the 2 week mark, but there's not been much discussion.
> > Anyone else want to weigh in?
> >
> > I want to give it a few more days and possibly revise it to include a Wiki
> > page as suggested, but probably will bring it to a vote within the next
> > week or so.
> >
>
> Hey Larry,
>
> As far as I can see, this RFC still doesn't address a primary concern from
> previous discussions: Extensions may get moved between PHP and PECL. The
> only discussion of this issue seems to be this bullet point:
>
> > If a feature is removed from PHP-SRC (either to PECL or dropped entirely)
> its previously claimed component namespace remains reserved. It MAY be
> released by a subsequent RFC, following the standard RFC procedure, at
> least one minor version after the feature is removed. That delay is to
> minimize backward compatibility impact and allow userland code to migrate
> if appropriate.
>
> To reiterate what the problem is: If the "PHP" namespace is only used by
> extensions bundled with php-src, then any time we import an extension from
> PECL, that means all the symbols in that extension must get renamed. This
> is disruptive to any existing users of the extension, who now have to deal
> with different symbol names depending on which PHP version they use.
>
> Similarly, when extensions get unbundled and moved to PECL, my current
> reading of your RFC is that the extension would initially retain the PHP\
> namespace prefix, even though it is no longer vendored by PHP, but the
> extension namespace may get reused at a later point in time (which seems
> counter-productive to the goal of avoiding naming collisions).
>
> For me, dealing with PHP <-> PECL moves is an important part of adopting
> namespaces in php-src, and I don't think the current proposal addresses
> this issue sufficiently. (One way to address it would be to drop the PHP\
> prefix, and use unvendored namespace names for php-src.)
>
> Regards,
> Nikita
Hi Nikita.
I'm open to ways of handling that. As written right now, yes, a hypothetical
\PHP\Foo extension getting moved to PECL should get renamed to \MyCorp\Foo (or
whatever). However, it should be reasonably straightforward in most cases to
include a user-space shim that does:
namespace \PHP\Fop {
class Service extends \MyCorp\Foo\Service {}
}
(Or similar.)
And the same for an extension moving into core.
I don't really see any alternative that doesn't either:
1) Essentially boil down to that.
2) Allow arbitrary extensions to share a namespace with core code.
Eg, one could say that core-packaged extensions and PECL both use \Ext, and
\PHP is reserved for the engine proper. However, there's not a great deal in
the engine proper, and stuff still sometimes moves from the engine to an
extension or vice versa, so
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On Tue, Jul 7, 2020 at 4:47 PM Larry Garfield wrote: > On Tue, Jun 23, 2020, at 7:30 PM, Larry Garfield wrote: > > Greetings, Internalians. > > > > There has been much talk of the \PHP namespace of late, including one > > unsuccessful RFC. In the discussion, the pushback broke down into two > > main camps: > > > > * We should never namespace anything ever. > > * We can namespace things but we need something more concrete than > > "RFCs can namespace things if they feel like it." > > > > I can't do much about the former, but the latter is a solvable problem. > > To that end, Mark Randall and I have put together a new RFC on the > > topic, based on a fruitful discussion in Room 11 a few weeks ago to > > brainstorm what actual guidelines should be for what goes where. > > > > https://wiki.php.net/rfc/php_namespace_policy > > > > This proposal provides guidance to short circuit future subjective > > bikeshedding, while still leaving some wiggle room for case-by-case > > evaluation as needed. That makes it different from prior attempts that > > did not provide clear guidance for future RFC authors. > > > > The specific guidelines offered may or may not appeal to you; those are > > open to discussion (within reason; we don't want to end up back in "do > > whatever" land as we know that won't help), but the more important > > point is that clear guidelines are provided. > > > > Also of note, although it uses existing code to demonstrate where > > classes *would* go under this plan it does not immediately move > > anything. Those are left for future RFCs that would have to stand or > > fall on their own merit. It also provides for a very long grace period > > for any such transitions to minimize disruption. > > > > The intent is to bring this proposal to a vote in time for 8.0's freeze > > one way or another, even though it's unlikely to have any impact on 8.0 > > itself. It's still a convenient deadline. > > > > *dons flame retardant suit* > > > > -- > > Larry Garfield > > la...@garfieldtech.com > > This has reached the 2 week mark, but there's not been much discussion. > Anyone else want to weigh in? > > I want to give it a few more days and possibly revise it to include a Wiki > page as suggested, but probably will bring it to a vote within the next > week or so. > Hey Larry, As far as I can see, this RFC still doesn't address a primary concern from previous discussions: Extensions may get moved between PHP and PECL. The only discussion of this issue seems to be this bullet point: > If a feature is removed from PHP-SRC (either to PECL or dropped entirely) its previously claimed component namespace remains reserved. It MAY be released by a subsequent RFC, following the standard RFC procedure, at least one minor version after the feature is removed. That delay is to minimize backward compatibility impact and allow userland code to migrate if appropriate. To reiterate what the problem is: If the "PHP" namespace is only used by extensions bundled with php-src, then any time we import an extension from PECL, that means all the symbols in that extension must get renamed. This is disruptive to any existing users of the extension, who now have to deal with different symbol names depending on which PHP version they use. Similarly, when extensions get unbundled and moved to PECL, my current reading of your RFC is that the extension would initially retain the PHP\ namespace prefix, even though it is no longer vendored by PHP, but the extension namespace may get reused at a later point in time (which seems counter-productive to the goal of avoiding naming collisions). For me, dealing with PHP <-> PECL moves is an important part of adopting namespaces in php-src, and I don't think the current proposal addresses this issue sufficiently. (One way to address it would be to drop the PHP\ prefix, and use unvendored namespace names for php-src.) Regards, Nikita
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On Thu, 9 Jul 2020 at 18:14, Derick Rethans wrote: > On Thu, 9 Jul 2020, Rowan Tommins wrote: > > > And yet we have repeatedly had discussions about whether this or that > > feature should or shouldn't be prefixed with a namespace. If you think > > the correct answer to "when should we use the PHP\ prefix?" is > > "never", I urge you to put forward an RFC making that the policy. > > That is already the policy: > https://www.php.net/manual/en/userlandnaming.rules.php > > Specifically "PHP owns the top-level namespace but tries to find decent > descriptive names and avoid any obvious clashes" > That is not the same thing at all. That states that PHP may use the global namespace; it doesn't say it will never use any other namespace. And https://www.php.net/manual/en/language.namespaces.rationale.php says essentially the same thing about the PHP\* namespace: > The Namespace name *PHP*, and compound names starting with this name (like *PHP\Classes*) are reserved for internal language use and should not be used in the userspace code. At the very least, it is not universally accepted that the policy is never to use the PHP namespace, or we wouldn't keep having this conversation. So, again, if anyone thinks that the policy should be to never use the PHP\ namespace prefix, please put it to a vote. (I'm quite tempted to do it myself from a position of Devil's Advocate.) Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On Thu, 9 Jul 2020, Rowan Tommins wrote: > And yet we have repeatedly had discussions about whether this or that > feature should or shouldn't be prefixed with a namespace. If you think > the correct answer to "when should we use the PHP\ prefix?" is > "never", I urge you to put forward an RFC making that the policy. That is already the policy: https://www.php.net/manual/en/userlandnaming.rules.php Specifically "PHP owns the top-level namespace but tries to find decent descriptive names and avoid any obvious clashes" cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On Thu, Jul 9, 2020, at 6:55 AM, Rowan Tommins wrote: > On Thu, 9 Jul 2020 at 09:58, Dan Ackroyd wrote: > > > On Tue, 7 Jul 2020 at 15:47, Larry Garfield > > wrote: > > > > > > This has reached the 2 week mark, but there's not been much discussion. > > > > Unless I'm having a massive reading failure, this RFC has been > > announced twice. And feedback was provided before: > > > > https://externals.io/message/109646#109647 > > https://externals.io/message/109646#109648 > > > > > It seems that, although still labelled version 1, the RFC has been > substantially rewritten since that discussion. Yes, based on the discussion in chat that resulted in actual guidelines, we mostly rewrote the whole document. I've no idea what the rules are around new version numbers of RFCs that haven't been up for a vote yet. > > From the RFC: > > > Every new global class, however, creates a potential namespace collision > > > with existing user-space code and thus a potential for backward > > > compatibility breaks. > > > > This doesn't appear to be an actual problem for the PHP ecosystem. > > > > The vast majority of code in libraries is in namespaces, which avoids > > there being a problem that needs addressing. > > > And yet we have repeatedly had discussions about whether this or that > feature should or shouldn't be prefixed with a namespace. If you think the > correct answer to "when should we use the PHP\ prefix?" is "never", I urge > you to put forward an RFC making that the policy. > > > > Rather than having more rules (quite a few of which I don't agree > > with), time and effort would be better spent on reviewing code and > > using features before releases e.g. to avoid situations like the FFI > > api being difficult to use. Which guidelines in particular bug you, and why? > > This is pure whataboutery; the idea that reading a few naming conventions > will be such a burden that somebody would have no time to review a feature > is frankly ridiculous. Nor will the lack of a naming convention mean that > no time needs to be spent naming things - quite the contrary, it will mean > more time is wasted debating every case. > > It's worth stressing that naming conventions are not new - we've had them > for global functions for many many years. We may talk about "putting things > into namespaces", but PHP's namespaces really are just names, so this RFC > could easily be called "update naming conventions for classes". I fully agree that this is a why-not-both-girl.gif situation. If anything, reducing the time that gets spent asking "*now* can we start using a namespace?" will open up more time for people to actually review APIs. Although since those are two very different mindsets I doubt that there will be any impact on available-API-review time either way. (That said, more time and attention paid to developing clean, usable APIs can only benefit PHP.) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On Thu, 9 Jul 2020 at 09:58, Dan Ackroyd wrote: > On Tue, 7 Jul 2020 at 15:47, Larry Garfield > wrote: > > > > This has reached the 2 week mark, but there's not been much discussion. > > Unless I'm having a massive reading failure, this RFC has been > announced twice. And feedback was provided before: > > https://externals.io/message/109646#109647 > https://externals.io/message/109646#109648 It seems that, although still labelled version 1, the RFC has been substantially rewritten since that discussion. > From the RFC: > > Every new global class, however, creates a potential namespace collision > > with existing user-space code and thus a potential for backward > > compatibility breaks. > > This doesn't appear to be an actual problem for the PHP ecosystem. > > The vast majority of code in libraries is in namespaces, which avoids > there being a problem that needs addressing. > And yet we have repeatedly had discussions about whether this or that feature should or shouldn't be prefixed with a namespace. If you think the correct answer to "when should we use the PHP\ prefix?" is "never", I urge you to put forward an RFC making that the policy. > Rather than having more rules (quite a few of which I don't agree > with), time and effort would be better spent on reviewing code and > using features before releases e.g. to avoid situations like the FFI > api being difficult to use. > This is pure whataboutery; the idea that reading a few naming conventions will be such a burden that somebody would have no time to review a feature is frankly ridiculous. Nor will the lack of a naming convention mean that no time needs to be spent naming things - quite the contrary, it will mean more time is wasted debating every case. It's worth stressing that naming conventions are not new - we've had them for global functions for many many years. We may talk about "putting things into namespaces", but PHP's namespaces really are just names, so this RFC could easily be called "update naming conventions for classes". Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On Tue, 7 Jul 2020 at 15:47, Larry Garfield wrote: > > This has reached the 2 week mark, but there's not been much discussion. Unless I'm having a massive reading failure, this RFC has been announced twice. And feedback was provided before: https://externals.io/message/109646#109647 https://externals.io/message/109646#109648 >From the RFC: > Every new global class, however, creates a potential namespace collision > with existing user-space code and thus a potential for backward > compatibility breaks. This doesn't appear to be an actual problem for the PHP ecosystem. The vast majority of code in libraries is in namespaces, which avoids there being a problem that needs addressing. > Anyone else want to weigh in? I still don't think this RFC is a good way to improve the general situation of PHP. Rather than having more rules (quite a few of which I don't agree with), time and effort would be better spent on reviewing code and using features before releases e.g. to avoid situations like the FFI api being difficult to use. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On Tue, Jul 7, 2020, at 5:31 PM, David Rodrigues wrote: > There are some problem by using double back slash for PHP namespace? > > Eg. Instead of \PHP\String be just \\String. Currently that's a syntax error, and I don't think we have time to change it before the code freeze even if we could all agree to do so. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
> On 8 Jul 2020, at 13:16, Michał Marcin Brzuchalski
> wrote:
>
> Hi Stephen,
>
> śr., 8 lip 2020 o 07:09 Stephen Reay napisał(a):
>
>> ...
>> IMO (and I know it’s not universal) acronyms should remain upper case.
>> Camel case is about upper casing the first letter of each word. The letters
>> of an acronym are all the first letters of words, thus DOM not Dom, etc.
>>
>
> It doesn't really matter much though, since core symbols are already known
> on runtime so symbol resolution works by case insensitive manner.
> So it's only a matter of preference on documentation side.
>
> namespace Foo\Bar {
>class BaZ {}
> }
> namespace {
>var_dump(new foo\bar\baz());
> }
>
> Cheers,
> --
> Michał Marcin Brzuchalski
Hi Michal,
I realise that - I was replying to a specific question about bike shedding the
capitalisation - that it works in other cases is irrelevant IMO.
Cheers
Stephen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
Hi Stephen,
śr., 8 lip 2020 o 07:09 Stephen Reay napisał(a):
> ...
> IMO (and I know it’s not universal) acronyms should remain upper case.
> Camel case is about upper casing the first letter of each word. The letters
> of an acronym are all the first letters of words, thus DOM not Dom, etc.
>
It doesn't really matter much though, since core symbols are already known
on runtime so symbol resolution works by case insensitive manner.
So it's only a matter of preference on documentation side.
namespace Foo\Bar {
class BaZ {}
}
namespace {
var_dump(new foo\bar\baz());
}
Cheers,
--
Michał Marcin Brzuchalski
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
> On 8 Jul 2020, at 05:11, Larry Garfield wrote: > > On Tue, Jul 7, 2020, at 4:22 PM, Miguel Rosales wrote: >> Larry Garfield wrote on 07/07/2020 16:46: >>> This has reached the 2 week mark, but there's not been much discussion. >>> Anyone else want to weigh in? >>> >> >> I guess I'm missing something obvious here, but the RFC says: >> >>> 5. Component or sub-component namespaces MUST use CamelCase naming >> conventions. >> >> But then in the examples you've got e.g. \PHP\DOM\ or \PHP\SPL\... isn't >> that incorrect? >> >> And slightly related, is there any reason to use \PHP instead of \Php? >> >> Sorry if this has been discussed before, I haven't seen it. >> >> Cheers, >> Miguel > > Mm, mainly because I added the CamelCase clause late and didn't think about > abbreviations. Whether it should be PHP/XML/DOM or Php/Xml/Dom has been an > ongoing debate for at least since PHP 5.0. I have no preference strong > enough to die on that hill, though, so whatever voters are willing to go for > I'm good with. > > Anyone care enough to offer a bikeshed color? > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > Hi Larry, IMO (and I know it’s not universal) acronyms should remain upper case. Camel case is about upper casing the first letter of each word. The letters of an acronym are all the first letters of words, thus DOM not Dom, etc. Cheers Stephen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
There are some problem by using double back slash for PHP namespace? Eg. Instead of \PHP\String be just \\String. Em ter, 7 de jul de 2020 19:04, Larry Garfield escreveu: > On Tue, Jul 7, 2020, at 4:22 PM, Miguel Rosales wrote: > > Larry Garfield wrote on 07/07/2020 16:46: > > > This has reached the 2 week mark, but there's not been much > discussion. Anyone else want to weigh in? > > > > > > > I guess I'm missing something obvious here, but the RFC says: > > > > > 5. Component or sub-component namespaces MUST use CamelCase naming > > conventions. > > > > But then in the examples you've got e.g. \PHP\DOM\ or \PHP\SPL\... isn't > > that incorrect? > > > > And slightly related, is there any reason to use \PHP instead of \Php? > > > > Sorry if this has been discussed before, I haven't seen it. > > > > Cheers, > > Miguel > > Mm, mainly because I added the CamelCase clause late and didn't think > about abbreviations. Whether it should be PHP/XML/DOM or Php/Xml/Dom has > been an ongoing debate for at least since PHP 5.0. I have no preference > strong enough to die on that hill, though, so whatever voters are willing > to go for I'm good with. > > Anyone care enough to offer a bikeshed color? > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On Tue, Jul 7, 2020, at 4:22 PM, Miguel Rosales wrote: > Larry Garfield wrote on 07/07/2020 16:46: > > This has reached the 2 week mark, but there's not been much discussion. > > Anyone else want to weigh in? > > > > I guess I'm missing something obvious here, but the RFC says: > > > 5. Component or sub-component namespaces MUST use CamelCase naming > conventions. > > But then in the examples you've got e.g. \PHP\DOM\ or \PHP\SPL\... isn't > that incorrect? > > And slightly related, is there any reason to use \PHP instead of \Php? > > Sorry if this has been discussed before, I haven't seen it. > > Cheers, > Miguel Mm, mainly because I added the CamelCase clause late and didn't think about abbreviations. Whether it should be PHP/XML/DOM or Php/Xml/Dom has been an ongoing debate for at least since PHP 5.0. I have no preference strong enough to die on that hill, though, so whatever voters are willing to go for I'm good with. Anyone care enough to offer a bikeshed color? --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On Tue, 7 Jul 2020 at 15:47, Larry Garfield wrote: > This has reached the 2 week mark, but there's not been much discussion. > Anyone else want to weigh in? > Looks good; nothing more to say. Peter
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On 07/07/2020 15:46, Larry Garfield wrote: This has reached the 2 week mark, but there's not been much discussion. Anyone else want to weigh in? We wanted to add that, general sentiment seems to be moving towards using Exceptions for communicating errors, potentially including a large effort towards it for 8.1. This would mean that each extension would likely need to add many of its own exception classes to build up a full hierarchy, all of which, in the current setup, would go into root. With this RFC passed we could realistically expect them to be placed into their respective namespaces keeping the whole thing much more self contained and tidy. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On Tue, Jun 23, 2020, at 7:30 PM, Larry Garfield wrote: > Greetings, Internalians. > > There has been much talk of the \PHP namespace of late, including one > unsuccessful RFC. In the discussion, the pushback broke down into two > main camps: > > * We should never namespace anything ever. > * We can namespace things but we need something more concrete than > "RFCs can namespace things if they feel like it." > > I can't do much about the former, but the latter is a solvable problem. > To that end, Mark Randall and I have put together a new RFC on the > topic, based on a fruitful discussion in Room 11 a few weeks ago to > brainstorm what actual guidelines should be for what goes where. > > https://wiki.php.net/rfc/php_namespace_policy > > This proposal provides guidance to short circuit future subjective > bikeshedding, while still leaving some wiggle room for case-by-case > evaluation as needed. That makes it different from prior attempts that > did not provide clear guidance for future RFC authors. > > The specific guidelines offered may or may not appeal to you; those are > open to discussion (within reason; we don't want to end up back in "do > whatever" land as we know that won't help), but the more important > point is that clear guidelines are provided. > > Also of note, although it uses existing code to demonstrate where > classes *would* go under this plan it does not immediately move > anything. Those are left for future RFCs that would have to stand or > fall on their own merit. It also provides for a very long grace period > for any such transitions to minimize disruption. > > The intent is to bring this proposal to a vote in time for 8.0's freeze > one way or another, even though it's unlikely to have any impact on 8.0 > itself. It's still a convenient deadline. > > *dons flame retardant suit* > > -- > Larry Garfield > la...@garfieldtech.com This has reached the 2 week mark, but there's not been much discussion. Anyone else want to weigh in? I want to give it a few more days and possibly revise it to include a Wiki page as suggested, but probably will bring it to a vote within the next week or so. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
> On Jun 23, 2020, at 8:30 PM, Larry Garfield wrote: > > Greetings, Internalians. > > There has been much talk of the \PHP namespace of late, including one > unsuccessful RFC. In the discussion, the pushback broke down into two main > camps: > > * We should never namespace anything ever. > * We can namespace things but we need something more concrete than "RFCs can > namespace things if they feel like it." > > I can't do much about the former, but the latter is a solvable problem. To > that end, Mark Randall and I have put together a new RFC on the topic, based > on a fruitful discussion in Room 11 a few weeks ago to brainstorm what actual > guidelines should be for what goes where. > > https://wiki.php.net/rfc/php_namespace_policy > > This proposal provides guidance to short circuit future subjective > bikeshedding, while still leaving some wiggle room for case-by-case > evaluation as needed. That makes it different from prior attempts that did > not provide clear guidance for future RFC authors. > > The specific guidelines offered may or may not appeal to you; those are open > to discussion (within reason; we don't want to end up back in "do whatever" > land as we know that won't help), but the more important point is that clear > guidelines are provided. > > Also of note, although it uses existing code to demonstrate where classes > *would* go under this plan it does not immediately move anything. Those are > left for future RFCs that would have to stand or fall on their own merit. It > also provides for a very long grace period for any such transitions to > minimize disruption. > > The intent is to bring this proposal to a vote in time for 8.0's freeze one > way or another, even though it's unlikely to have any impact on 8.0 itself. > It's still a convenient deadline. > > *dons flame retardant suit* > This looks really good Larry. Very well thought-out. If I could vote it would be a definitive "Yes." -Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On Wed, Jun 24, 2020, at 2:32 PM, Rowan Tommins wrote: > On 24/06/2020 01:30, Larry Garfield wrote: > > * We should never namespace anything ever. > > * We can namespace things but we need something more concrete than "RFCs > > can namespace things if they feel like it." > > > > I can't do much about the former, but the latter is a solvable problem. To > > that end, Mark Randall and I have put together a new RFC on the topic > > > Hi Larry, > > Thanks for moving forwards with this. To stretch an analogy, I think > we're better off picking out the colour scheme for this bikeshed in > advance, rather than just resolving to buy some paint when we need it. :) Ha! An apt analogy, yes. > One section that gave me pause reading the RFC was this: > > > A component namespace is “claimed” by the RFC that first uses it. > Once claimed, that component namespace may only be used only by that RFC > or future RFCs that extend that one in a natural way. > > PHP RFCs tend to describe a change rather than a full feature, and once > accepted are more a historical record of the change than a living > reference. Perhaps it would make sense to create an IANA-style > "registry" of reserved "component namespaces", so that RFCs could add, > and more rarely amend, entries in a central location. > > This doesn't need to be elaborate - just a table on a wiki page > somewhere, with columns such as name, usage definition, status (e.g. > unused but reserved for forward/backwards compatibility), and maybe > notes on naming conventions within the component (use of sub-namespaces, > suffixes, etc). I didn't want to over-reach, as I am not familiar enough with other Wiki processes etc. to know what the rules would be for establishing such a registry. I agree it's a good idea, though, if someone can suggest workable logistics. A wiki page or a page in docs would both make sense to me. > One thing the RFC doesn't tackle in detail is what we might call The > PECL Question: what are the processes when an extension moves from PECL > to php-src (like ext/sodium) or from php-src to PECL (like ext/mysql)? > > For moves into PECL, the RFC says that the component namespace "remains > reserved". If we were maintaining a registry, this could include links > to PECL with appropriate status notes. > > For moves out of PECL, it's trickier. If we have PECL extensions listed > on the registry, we could have some way to register them *before* the > extension is added to core; but I'm not quite sure what that process > would look like, and what kind of endorsement it would imply of the > extension. > > If we don't do that, what would happen when an extension becomes part of > core and needs to rename functionality from "Foo\Something" or > "SomeCorp\Foo\Something" to "PHP\Foo\Something"? > > One answer would be to follow the same process as renaming functionality > already in core - i.e. include the old names as aliases, subject to > deprecation over a major version cycle. This would help users migrating > from the PECL extension, but users of "vanilla" php-src might be > confused why there are two names. Worse, it would defeat part of the > point of the PHP\* namespace, since php-src would be claiming names > outside it which could conflict with other projects. > > Perhaps a cleaner approach would be to add the extension with only the > new PHP\* names, and provide a userland polyfill for users upgrading > from the PECL extension? Mark had discussed having a \PHP\Ext\ namespace for extensions. I deal with extensions rarely enough that I don't have a strong opinion on the matter. I'm fine with no Ext segment, but if others feel strongly about having it that's good too. Whatever is agreeable works for me. We could also pre-reserve a namespace for PECL packages in general to use if that makes sense to people. For transitioning in/out, my feeling is: * On the way in, it's a new feature for php-src so follows the same rules as any other new php-src code. * User-space polyfills should be a reasonable and straightforward thing to do *most* of the time, so that's fine. * On the way out, the namespace remains reserved for a while so a user-space polyfill is just as viable. * These are heuristics, not absolute rules, so if a particular extension really really has need to be different that's OK, and we explicitly give ourselves wiggle room should that be needed. The goal here is to make it clear what the default policy is and where the burden of proof is to demonstrate a need to be non-default. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On 24/06/2020 01:30, Larry Garfield wrote: * We should never namespace anything ever. * We can namespace things but we need something more concrete than "RFCs can namespace things if they feel like it." I can't do much about the former, but the latter is a solvable problem. To that end, Mark Randall and I have put together a new RFC on the topic Hi Larry, Thanks for moving forwards with this. To stretch an analogy, I think we're better off picking out the colour scheme for this bikeshed in advance, rather than just resolving to buy some paint when we need it. :) One section that gave me pause reading the RFC was this: > A component namespace is “claimed” by the RFC that first uses it. Once claimed, that component namespace may only be used only by that RFC or future RFCs that extend that one in a natural way. PHP RFCs tend to describe a change rather than a full feature, and once accepted are more a historical record of the change than a living reference. Perhaps it would make sense to create an IANA-style "registry" of reserved "component namespaces", so that RFCs could add, and more rarely amend, entries in a central location. This doesn't need to be elaborate - just a table on a wiki page somewhere, with columns such as name, usage definition, status (e.g. unused but reserved for forward/backwards compatibility), and maybe notes on naming conventions within the component (use of sub-namespaces, suffixes, etc). One thing the RFC doesn't tackle in detail is what we might call The PECL Question: what are the processes when an extension moves from PECL to php-src (like ext/sodium) or from php-src to PECL (like ext/mysql)? For moves into PECL, the RFC says that the component namespace "remains reserved". If we were maintaining a registry, this could include links to PECL with appropriate status notes. For moves out of PECL, it's trickier. If we have PECL extensions listed on the registry, we could have some way to register them *before* the extension is added to core; but I'm not quite sure what that process would look like, and what kind of endorsement it would imply of the extension. If we don't do that, what would happen when an extension becomes part of core and needs to rename functionality from "Foo\Something" or "SomeCorp\Foo\Something" to "PHP\Foo\Something"? One answer would be to follow the same process as renaming functionality already in core - i.e. include the old names as aliases, subject to deprecation over a major version cycle. This would help users migrating from the PECL extension, but users of "vanilla" php-src might be confused why there are two names. Worse, it would defeat part of the point of the PHP\* namespace, since php-src would be claiming names outside it which could conflict with other projects. Perhaps a cleaner approach would be to add the extension with only the new PHP\* names, and provide a userland polyfill for users upgrading from the PECL extension? Regards, -- Rowan Tommins (né Collins) [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] \PHP namespace usage heuristics
Greetings, Internalians. There has been much talk of the \PHP namespace of late, including one unsuccessful RFC. In the discussion, the pushback broke down into two main camps: * We should never namespace anything ever. * We can namespace things but we need something more concrete than "RFCs can namespace things if they feel like it." I can't do much about the former, but the latter is a solvable problem. To that end, Mark Randall and I have put together a new RFC on the topic, based on a fruitful discussion in Room 11 a few weeks ago to brainstorm what actual guidelines should be for what goes where. https://wiki.php.net/rfc/php_namespace_policy This proposal provides guidance to short circuit future subjective bikeshedding, while still leaving some wiggle room for case-by-case evaluation as needed. That makes it different from prior attempts that did not provide clear guidance for future RFC authors. The specific guidelines offered may or may not appeal to you; those are open to discussion (within reason; we don't want to end up back in "do whatever" land as we know that won't help), but the more important point is that clear guidelines are provided. Also of note, although it uses existing code to demonstrate where classes *would* go under this plan it does not immediately move anything. Those are left for future RFCs that would have to stand or fall on their own merit. It also provides for a very long grace period for any such transitions to minimize disruption. The intent is to bring this proposal to a vote in time for 8.0's freeze one way or another, even though it's unlikely to have any impact on 8.0 itself. It's still a convenient deadline. *dons flame retardant suit* -- Larry Garfield la...@garfieldtech.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
