Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76841
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.180 as permitted sender)
Message-ID: <53F8D7FC.60005@gmail.com>
Date: Sat, 23 Aug 2014 19:05:48 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "internals@lists.php.net" <internals@lists.php.net>
References: <CAGa2bXYqHCSvatYHoc2j48eqc2oMG6XwOOUxdOFxuvB6eZHiuw@mail.gmail.com> <53D8E693.8000406@gmail.com> <CAGa2bXYG=ki41ucvRnbx9Vuq-regdLbFb8aipP7waFGis0kwmA@mail.gmail.com> <53F0CA22.10608@gmail.com> <CAGa2bXZJ=reVcCUfMCXD33MtKueL8P_8wwXqGvnqv7AOBc_nwA@mail.gmail.com>
In-Reply-To: <CAGa2bXZJ=reVcCUfMCXD33MtKueL8P_8wwXqGvnqv7AOBc_nwA@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------070209060902020609010901"
Subject: Re: [PHP-DEV] "PHP" namespace?
From: rowan.collins@gmail.com (Rowan Collins)

--------------070209060902020609010901
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 23/08/2014 04:39, Yasuo Ohgaki wrote:
> Hi Rowan,
>
> On Mon, Aug 18, 2014 at 12:28 AM, Rowan Collins 
> <rowan.collins@gmail.com <mailto:rowan.collins@gmail.com>> wrote:
>
>     On 15/08/2014 01:46, Yasuo Ohgaki wrote:
>
>     I have previously been tempted by the thought of adding a new set
>     of functions with a clearer design, but on reflection, I realise
>     that you just end up making the problem worse: now the programmer
>     has to ask themselves extra questions, like "Does PHP\Array\map
>     take the arguments in the same order as array_map? Which am I
>     supposed to be using in this project?"
>
>
>     Add in namespace aliasing, or a magic ini setting that hides the
>     old functions and puts the new ones in their place, and reading
>     code becomes equally confusing: "When it says array_map here, is
>     that the classic PHP function, or a new version aliased in? What
>     differences are there between the two?"
>
>
> I'm not intended to divide global name space into parts.
> Current(most updated API) namespace and legacy(older API) namespace 
> would be enough. Namespace may have version. (5, 7, and so on)
> Therefore, user would not confuse like you describe.

It doesn't matter if you have 1, 5, or zero namespaces, the problem is 
having to learn more than one version of the same function.

If PHP\5\array_map and PHP\7\array_map took different arguments, the 
language would be harder to learn, not easier.


>
> For example, when a library major version incremented, API may differ. 
> Users may use new or old API selectively. I would like to have a 
> choice to use cleaner API or older API like library API.
>
> If we divide namespace into pieces and change API frequently (i.e with 
> minor or bugfix version up), then it's confusing for sure. I'll 
> against such usage.

I'm not sure what dividing the namespace into pieces has to do with 
frequent updates. My feeling is that if you're going to go with 
namespaces, you might as well actually use them to group functions, so 
rather than PHP\array_map (or PHP\7\array_map) it could be PHP\Array\map 
(or PHP\7\Array\map).


>
>     Individual users can't choose, because they will be contributing
>     to projects - be they open source or commercial - with coding
>     standards based on the platforms supported, the size of the
>     existing code base, and the prejudices of project leaders. And the
>     current trend in open source projects is towards more co-operation
>     and standardisation (e.g. PHP-FIG), so adding a new thing to
>     disagree on would be unfortunate to say the least.
>
>
> Libraries/Projects may choose appropriate namespace (e.g. 5, 7, and so 
> on) like choosing specific library version mostly.

Yes, and users making use of and contributing to multiple projects will 
have to learn both versions. Thus the more subtle variations there are 
between the versions, the more they'll have to learn.

You also didn't respond to my point that introducing the extra choice 
means one more barrier to smooth co-operation between projects.


>         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.
>
>
>     So what is it you suggest instead? A series of namespaces with
>     slightly different versions of all the functions, introduced over
>     time, and every file having to declare at the top "use PHP7;",
>     "use PHP8;" etc?
>
>
> Yes. Something like this.
> Since 'PHP' is reserved namespace name, "PHP\5", "PHP\7", "PHP\8" perhaps.

This sounds like a recipe for massive confusion to me, for the reasons 
I've already tried to explain.


>
>
>         Use of namespace guarantees new PHP has consistent/modern API.
>         This will neutralize/negate all cons, IMO.
>
>
>     I'm really not sure what problems adding one or more namspaces solves.
>
>     If you just arrange the existing functions into namespaces with
>     better naming conventions, then it's just the same as any other
>     set of aliases; it's clear which are the "old" names and which the
>     "new", but that's about the only benefit. If you make the
>     functions superficially similar, but with minor changes like
>     argument order or error-handling, then the cost of adoption is
>     even higher.
>
>
> I like alias also and have proposed use of aliases before.
> It may be good idea to use aliases as much as possible for simple name 
> changes.
>
> Whole point of namespace use is to remove small inconsistency and/or 
> improper names (e.g. SessionHandlerInterface) with major release so 
> that small inconsistency would not be added up and have cleaner API 
> for new major versions.

You can make the changes without introducing namespaces, so saying that 
the point of namespaces is to make changes makes no sense. I think what 
you're getting at is that namespaces allow PHP to contain *multiple 
versions of the same function or class*, which aren't simply aliases, 
but have different behaviour in some way.

That provides a smoother upgrade path (or, at least, lets people put off 
that upgrade), but it doesn't negate the problem of programmers having 
to know both versions, or the huge amount of existing code examples 
which won't work correctly under some environments because "use PHP\7;" 
is in effect.

Incidentally, I'm not sure what the problem with SessionHandlerInterface 
is, which you keep mentioning as an example.


> Besides function/method name aliasing, changes in namespace would be 
> small enough to adopt/learn. New major release has long list of 
> changes always. Adding a few would not make much difference. IMHO.

It's quite hard to generalise about the changes in major releases, since 
it's 10 years since the last one, and the project is in a very different 
place than it was then. And as Derick pointed out in another thread, 
it's very risky to go from "we can make such changes if necessary" to 
"we can make as many changes as we feel like".


>
> PHP allows overriding strlen() by mb_strlen(), etc, with namespace 
> already. (Unless there is a function byte_len(), this would not be 
> practical as you mentioned. If "PHP" namespace is used, programmers 
> may write "PHP\5\strlen($str);", though.)

Yes, but the use of this makes code harder to read, and harder to 
maintain. To design a feature aimed entirely at making a function name 
mean different things in different files, and to do so in the name of 
consistency and a clean API, seems counter-productive.


>
>
>     The reason I think major changes are less likely to fail than
>     minor ones is that you can avoid the confusion of which version is
>     which, and offer a much stronger benefit to adopting the new
>     style. For instance, "scalar methods" are both very distinct from
>     existing code, and naturally give actions a "subject", e.g. $a =
>     [1,3,2]; $a->map($callback); They have the inherent attraction
>     (for some people) of giving code an OO flavour.
>
>
> I like the idea and I'm +1 for this.
> There is such RFC also.
> https://wiki.php.net/rfc/autoboxing
>
> BTW, I also preferred to keep procedural API. Everything does not have 
> to be an object and I would like to have choice (e.g MySQLi, session 
> save handler)

The point is not (necessarily) that "everything should be an object", 
it's that a big visible change makes it obvious that the new API is 
being used.


> Using namespace for cleaning current API is just an idea.
> I'll write a FRC when I came up with concrete idea and hope you like it.

Like I say, I used to think it would be a good idea, but now see it 
introducing just as many problems as it solves.

-- 
Rowan Collins
[IMSoP]


--------------070209060902020609010901--