Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76221
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH-PCH69d8NEjm6v0BypQU13HhrDYezZQV0mN0D+1krqCSaVFw@mail.gmail.com>
References: <CAGa2bXYqHCSvatYHoc2j48eqc2oMG6XwOOUxdOFxuvB6eZHiuw@mail.gmail.com>
 <CAH-PCH69d8NEjm6v0BypQU13HhrDYezZQV0mN0D+1krqCSaVFw@mail.gmail.com>
Date: Mon, 28 Jul 2014 09:49:31 +0100
Message-ID: <CAPg3XxLu6Jo7HjkxXcWZxw77a12aWzEypYf4FFO63S=xqEnLDQ@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113a9556c4d22204ff3d020d
Subject: Re: [PHP-DEV] "PHP" namespace?
From: petercowburn@gmail.com (Peter Cowburn)

--001a113a9556c4d22204ff3d020d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 28 July 2014 09:22, Ferenc Kovacs <tyra3l@gmail.com> wrote:

> 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
> be
> > nice
> > to have.
> >
> > Currently, PHP module functions/classes/interfaces are using global(roo=
t)
> > namespace.
> > If it is changed to use its own namespace, user space APIs may be chang=
ed
> > 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/constant=
s
> >
> > // 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
> > yohgaki@ohgaki.net
> >
>
> hi,
>
> I think it would make sense to announce that the php namespace is reserve=
d
> for internal use, but I don't think that we are ready for moving everythi=
ng
> 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/clas=
s,
> 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 w=
e
> 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=C3=A1cs
> @Tyr43l - http://tyrael.hu
>

[1] http://php.net/manual/en/language.namespaces.rationale.php

--001a113a9556c4d22204ff3d020d--