Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109660
MIME-Version: 1.0
References: <CABdc3WoTeO4eTAoHCfqKyy8PWjrn97w9JXXhD88c3O9xPzp7QQ@mail.gmail.com>
 <CAOsHV+srDeL3FxcWkKZw3qZ8FaA3oBqOyPuot7fhjeyNZO46rw@mail.gmail.com>
In-Reply-To: <CAOsHV+srDeL3FxcWkKZw3qZ8FaA3oBqOyPuot7fhjeyNZO46rw@mail.gmail.com>
Date: Wed, 15 Apr 2020 18:49:44 +0200
Message-ID: <CABdc3WrD_6czePZcvLQdmo_8bdK=4e7grrMEPAZP5s1fnAbDkw@mail.gmail.com>
To: Marcio Almada <marcio.web2@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002b2faf05a3571bc9"
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] PHP Namespace in core
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--0000000000002b2faf05a3571bc9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Marcio,

=C5=9Br., 15 kwi 2020 o 18:39 Marcio Almada <marcio.web2@gmail.com> napisa=
=C5=82(a):

> >
> > Hi internals,
> >
> > I hope you're doing well.
> >
> > I'd like to announce the PHP Namespace in core RFC for discussion.
> > The RFC is authored by me together with George Peter Banyard and it's
> > purpose
> > is nothing more like to allow the use of PHP Namespace in the core.
> >
> > The RFC is described at https://wiki.php.net/rfc/php-namespace-in-core
> >
> > Best Regards,
> > Micha=C5=82 Brzuchalski
>
> Hello,
>
> 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 namespac=
e
> 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 implementations in
PHP or by wrapping around a C library.
The features tightly coupled with the language is for eg. the Reflection
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 proposal
is to allow features like that to use PHP namespace.

Cheers,
Micha=C5=82 Brzuchalski

--0000000000002b2faf05a3571bc9--