On Tue, 28 Apr 2020 at 12:52, Max Semenik wrote:
> On Tue, Apr 28, 2020 at 11:45 AM Rowan Tommins
> wrote:
>
>> One prefix doesn't make a trend. "PhpToken" is a different case - it's a
>> token of PHP source code, so the prefix isn't anything to do with avoiding
>> name collisions, it's a natura
On Tue, Apr 28, 2020 at 11:45 AM Rowan Tommins
wrote:
> One prefix doesn't make a trend. "PhpToken" is a different case - it's a
> token of PHP source code, so the prefix isn't anything to do with avoiding
> name collisions, it's a natural clarification.
>
There's also SPL, with classes like Spl
On Mon, 27 Apr 2020 at 23:22, Mike Schinkel wrote:
> > On Apr 27, 2020, at 6:05 PM, Rowan Tommins
> wrote:
> >
> > So you'd be happy with PHP\str_contains and \str_replace next to each
> other indefinitely?
>
> Absolutely. The benefits of having a PHP namespace would outweigh the
> lack of ele
> On Apr 27, 2020, at 6:05 PM, Rowan Tommins wrote:
>
> So you'd be happy with PHP\str_contains and \str_replace next to each other
> indefinitely?
Absolutely. The benefits of having a PHP namespace would outweigh the lack of
elegance above.
OTOH I'm not sure why we could not have *both* \
On 27/04/2020 22:40, Mike Schinkel wrote:
How about a simply policy: Newer things go in, older ones stay out?
Check the docs to see which is which if you are unsure, or just let your IDE
auto-complete for you.
So you'd be happy with PHP\str_contains and \str_replace next to each
other inde
> On Apr 27, 2020, at 4:25 AM, Rowan Tommins wrote:
>
> To me, the answer to that is quite simple: we have several hundred
> functions, and several dozen classes and interfaces, which are not in such
> a namespace; and we have millions of lines of code out in the world using
> them. So ... we nee
On 15/04/2020 14:20, Remi Collet wrote:
Le 15/04/2020 à 13:21, Mark Randall a écrit :
Extension (pecl or other) can be include in core later
or core extension dropped and move to pecl.
Quoting the RFC:
Once approved, a namespace that is a child of \PHP will remain
exclusively for the original
Le 15/04/2020 à 13:21, Mark Randall a écrit :
> Greetings,
>
> I would like to re-open the discussion on properly reserving the \PHP
> namespace for the use of the engine and its core extensions.
What does that mean for PECL extension ?
If they have to use another namespace,
sorry, but I will vo
On 15/04/2020 12:40, Dan Ackroyd wrote:
Another benefit of having core PHP symbols in the root namespace is
that it means we can avoid having the discussion of what the namespace
naming rules should be. Again, the tradeoff of having to spend time on
that discussion of how to name things vs a poss
On 15/04/2020 12:23, Derick Rethans wrote:
This will mean that in a future version of PHP, some things will live in
a \PHP namespace, and others, such as DateTimeImmutable or Directory do
not. We should not be introducing inconsistencies.
It notes that it should be the preferred method for new
On Wed, 15 Apr 2020 at 12:21, Mark Randall wrote:
>
> Rather than seek to demand everything be moved into namespaces, I have
> instead written this RFC as something that would form a policy
> guideline for future development of the engine and those extensions
> which are directly managed by intern
Hi Mark,
On Wed, 15 Apr 2020, Mark Randall wrote:
> I would like to re-open the discussion on properly reserving the \PHP
> namespace for the use of the engine and its core extensions.
I will be voting no against this. The RFC states:
By design this RFC does NOT propose moving anything exis
Greetings,
I would like to re-open the discussion on properly reserving the \PHP
namespace for the use of the engine and its core extensions.
Rather than seek to demand everything be moved into namespaces, I have
instead written this RFC as something that would form a policy
guideline for future
13 matches
Mail list logo
