Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109667
MIME-Version: 1.0
References: <CABdc3WoTeO4eTAoHCfqKyy8PWjrn97w9JXXhD88c3O9xPzp7QQ@mail.gmail.com>
 <CAOsHV+srDeL3FxcWkKZw3qZ8FaA3oBqOyPuot7fhjeyNZO46rw@mail.gmail.com>
 <CABdc3WrD_6czePZcvLQdmo_8bdK=4e7grrMEPAZP5s1fnAbDkw@mail.gmail.com> <5e974337.1c69fb81.62230.5d05SMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <5e974337.1c69fb81.62230.5d05SMTPIN_ADDED_MISSING@mx.google.com>
Date: Wed, 15 Apr 2020 21:53:40 +0200
Message-ID: <CAFPFaMK6441wugP+nwdXXZLLpRs3dMJb_kKNih1xBsDPs4Gt1g@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000dc391605a359acf5"
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] PHP Namespace in core
From: george.banyard@gmail.com ("G. P. B.")

--000000000000dc391605a359acf5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 15 Apr 2020 at 19:24, Andrea Faulds <ajf@ajf.me> wrote:

> Hi,
>
> Micha=C5=82 Brzuchalski wrote:
> > Hi Marcio,
> >
> > =C5=9Br., 15 kwi 2020 o 18:39 Marcio Almada <marcio.web2@gmail.com>
> napisa=C5=82(a):
> >
> >> Even though I'm fond to the idea of languages having the official
> >> stdlib contained
> >> into a single space, there seems to be no practicality on a \PHP
> namespace
> >> usage
> >> at this point IMMO.
> >>
> >> We would be in a situation where things are either mixed in and out
> >> the new namespace
> >> - Should I `use function PHP\{json_encode, json_decode}` or was it in
> >> the root??? - or
> >> everything that already exists must first receive an alias into this
> >> new namespace, to allow
> >> consistency... but then there would probably be no plans ever to
> >> actually move existing stuff
> >> into the new prefix in the future.
> >>
> >>
> > You've misunderstood the idea. Standard library functions classes etc.
> are
> > not language features.
> > It's not a purpose of this RFC to move existing functions from the
> standard
> > library but to allow core language features
> > to use it. Described examples show benefit in use for symbols tightly
> > coupled to features PHP as a language delivers.
> >
> > Most of the standard library function can be replaced by implementation=
s
> in
> > PHP or by wrapping around a C library.
> > The features tightly coupled with the language is for eg. the Reflectio=
n
> > mechanism, PhpToken class as described.
> > Upcoming PhpAttributes for which proposal is a work in progress.
> >
> > Those all features will not likely be moved to PECL and this RFC propos=
al
> > is to allow features like that to use PHP namespace.
>
> We already have PHP language features relying on classes in the root
> namespace (Closure, Throwable, ArrayAccess, etc) so the point Marcio
> makes about inconsistency is nonetheless valid I think.
>
> Thanks,
> Andrea
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

The proposal is not to move everything into the PHP namespace.
I would even argue that these interface make more sense in the global
namespace as they are meant to be available to all users to implement
and extend.

This is in strong contract to the Reflection API which, at least, should no=
t
be extended by end users IMHO as it provided features which are heavily
tied to the engine and how it is implemented.
Now as Reflection is already an existing feature the objective here is not
to move the current one into the PHP namespace and alias it but possibly
provide a Reflection 2.0 API which is design with the benefit of hindsight.

A more relevant example, in my eyes, is the current proposal of attributes.
Engine attributes like JIT, NoJIT, and possibly in the future Deprecated
and/
or Final are features provided by the engine which should not have the
possibility to be extended by end users, only consumed.

Another example I can come up are scalar objects.
If PHP starts to provided scalar objects, I would imagine that they it won'=
t
be possible to extend them and only consume them, in the same way as
the current functions provided by ext/standard.
Or maybe a new API to interact with stream and/or the file system.

I hope this clarifies the intent behind the RFC.

Best regards

George P. Banyard

--000000000000dc391605a359acf5--