Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76529
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.171 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <53D8E693.8000406@gmail.com>
References: <CAGa2bXYqHCSvatYHoc2j48eqc2oMG6XwOOUxdOFxuvB6eZHiuw@mail.gmail.com>
 <53D8E693.8000406@gmail.com>
Date: Fri, 15 Aug 2014 09:46:40 +0900
Message-ID: <CAGa2bXYG=ki41ucvRnbx9Vuq-regdLbFb8aipP7waFGis0kwmA@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e013a06062621a40500a05d3e
Subject: Re: [PHP-DEV] "PHP" namespace?
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e013a06062621a40500a05d3e
Content-Type: text/plain; charset=UTF-8

Hi all,

On Wed, Jul 30, 2014 at 9:35 PM, Rowan Collins <rowan.collins@gmail.com>
wrote:

>
>    - Consistent naming
>>   - Consistent parameter order
>>   - Graceful function/class/interface deprecation
>> (We know what we should do for these, right?)
>>
>
> I'm not sure if this was meant sincerely, or slightly tongue-in-cheek, but
> no, we definitely don't. It comes up on the list every few months (I've
> only been subscribed a short time, but this is at least the 4th time I've
> seen), and the general conclusion is there isn't an easy answer, and that
> adding more namespaces doesn't particularly help.
>

One of the discussion is mine, I suppose.
This is because cleaning up API cannot be done w/o breaking some except
simple aliasing.
Even if there are issues in API, there isn't a consensus for feasible
resolution yet.

Namespace is good resolution obviously. It accomplishes compatibility and
consistency at the same time
even when parameters or class/interface definitions are changed.


> Making small changes, such as extra function aliases, or identical
> versions of existing functions with switched parameter order, just adds to
> the overall confusion and list of special cases that users have to carry
> around when reading and writing code.
>

We make small changes in versions always. API changes are small changes
also.
The difference is BC. Since API change breaks APP, it wasn't changed for a
long time.
Use of alias was proposed several times, but it wasn't optimum and couldn't
reach to consensus.

With namespace, user may choose. We don't force users to *new* or *old*
way. There is no BC issue.
It's users' choice. If we care about confusion, we may change API only with
major release to minimize it.


That leaves the option of making larger changes, to design a clear new API,
> deliberately *minimising* the similarity to existing functions so it's
> clear when you're using what. The popular option for that is migrating
> chunks of functionality to OOP (as with DateTime), and to pseudo-OOP
> "scalar methods" (of which there are a couple of prototypes) - not to turn
> PHP into a pure OOP language, just to give us a chance to design a more
> consistent library of functions.


Unless we rewrite everything completely, it wouldn't be accomplished. This
has been said for years
(more than a decade AFAIK) and didn't happen. Therefore, new API is not
feasible by history.

Even when we rewrite everything, are we going to remove old API? It's BC,
so I guess not. Most
legacy/obscure API will remain as it is now and usable by default.

New API doesn't help some time. For example, SessionHandlerInterface has
some variations and
has issue for adding to it. Instead having many SessionHandlerXXXInterface,
simply selecting
proper namespace is simpler/cleaner. Having new Session2 class only for
simpler interface name
does not make sense.

Since we don't have new major release often, it would be good for users
cleaning up API with every
new major versions. Otherwise, legacy/obscure APIs will remain 10 years or
even 20 years later for sure.
(In fact, we have legacy APIs almost 20 years that are used commonly)

Use of namespace guarantees new PHP has consistent/modern API. This will
neutralize/negate all cons, IMO.

cons are
 - New php.ini (default namesapce setting)
 - Legacy API can be used and remains (this is pros also)
 - Confusing to current users by having versions of API. (confusing API is
confusing for both new and current users, too)

If there are more cons, please add them.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--089e013a06062621a40500a05d3e--