On 28 July 2014 09:22, Ferenc Kovacs <tyr...@gmail.com> wrote: > On Mon, Jul 28, 2014 at 4:58 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > > > Hi all, > > > > Since we have discussion for Next PHP, "PHP" namespace discussion would > be > > 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('日本語')); > > ?> > > > > 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/constants > > 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 > > yohg...@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. >
For what it's worth, the manual already states that the "php" namespace is reserved for us.[1] > 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. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu > [1] http://php.net/manual/en/language.namespaces.rationale.php