Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76220
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXYqHCSvatYHoc2j48eqc2oMG6XwOOUxdOFxuvB6eZHiuw@mail.gmail.com>
References: <CAGa2bXYqHCSvatYHoc2j48eqc2oMG6XwOOUxdOFxuvB6eZHiuw@mail.gmail.com>
Date: Mon, 28 Jul 2014 10:22:44 +0200
Message-ID: <CAH-PCH69d8NEjm6v0BypQU13HhrDYezZQV0mN0D+1krqCSaVFw@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c21eda97057a04ff3ca052
Subject: Re: [PHP-DEV] "PHP" namespace?
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a11c21eda97057a04ff3ca052
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 28, 2014 at 4:58 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi all,
>
> Since we have discussion for Next PHP, "PHP" namespace discussion would b=
e
> nice
> to have.
>
> Currently, PHP module functions/classes/interfaces are using global(root)
> namespace.
> If it is changed to use its own namespace, user space APIs may be changed
> flexible and user controlled manner. Thus, PHP may have
>
>  - Consistent naming
>  - Consistent parameter order
>  - Graceful function/class/interface deprecation
> (We know what we should do for these, right?)
>
> without much compatibility issues.
>
>
> "PHP" namespace may be used to provide PHP(and 3rd party)
> functions/classes/interfaces/constants.
> "PHP\Legacy" (or whatever) may be used for legacy
> functions/classes/interfaces/constants.
>
> From PHP 5.6, userland function aliasing can be done with namespace.
> Following code overrides existing function.
>
> <?php
> use function \mb_strlen as strlen;
> var_dump(strlen('=E6=97=A5=E6=9C=AC=E8=AA=9E'));
> ?>
>
> Result:
> int(3)
>
> It's good to use prefered API, but it requires "use" for every function
> APIs to be overridden.
> Note: Classes/Interfaces may override by "use" one by one also.
>
> With "PHP" and "PHP\Legacy" namespace, user may write:
>
> <?php
> namespace PHP; // Use current PHP functions/classes/interfaces/constants
>
> // Code uses current API
> ?>
>
> <?php
> namespace PHP;
> namespace PHP\Legacy; // Override with legacy PHP
> functions/classes/interfaces/constants.
>
> // Code uses legacy API
> ?>
>
> For compatibility, default namespace setting would be nice to have.
>   - None for compiled default
>   - "PHP" for php.ini-*
>
> Previous example codes became:
>
> <?php
> // Code uses current API
> ?>
>
> <?php
> namespace PHP\Legacy; // Override with legacy PHP
> functions/classes/interfaces/constants.
> // Code uses legacy API
> ?>
>
> Issue would be codes that assume PHP functions/classes/interfaces/constan=
ts
> are
> defined in global(root) namespace. (e.g. \strlen()) This could be
> workaround by allowing
> "use"  aliasing to global(root) namespace. (e.g. "use PHP\Legacy as \;") =
In
> this case,
> current functions/classes/interfaces may stay in global(root) namespace.
> (or "use PHP as \;")
>
>
> Programmers may shoot their own foot by this. This is the trade off of
> flexibility.
>
> Any thoughts and/or comments?
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>

hi,

I think it would make sense to announce that the php namespace is reserved
for internal use, but I don't think that we are ready for moving everything
under namespaces.
The way we currently implement namespaces can't support wildcard imports so
the migration for project would be pretty tedious, finding and replacing
every occurance of a global function/class or use-ing every function/class,
etc.
namespaces has a bit clunky way of supporting constants: define always
assumes global ns(and the const syntax only allows scalar values so it
isn't always an option to use const).
moving the functions to namespaces would be also a bit weird for me, as we
currently don't support function (and const) autoloading, so it would be a
mixed message about whether or not do we consider functions and constants
first-class citizens used together with the later introduced oop features.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a11c21eda97057a04ff3ca052--