On 15/08/2014 01:46, Yasuo Ohgaki wrote:
On Wed, Jul 30, 2014 at 9:35 PM, Rowan Collins
<rowan.coll...@gmail.com <mailto:rowan.coll...@gmail.com>> wrote:
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.
When we talk about compatibility of an API, we are normally talking
about how an existing piece of code connects to another program,
library, or service. But when you're talking about the core functions of
a language, the consumer of that API is the programmer themselves, when
writing new code and reading old.
One of the problems which we would like to fix is that pogrammers have
to stop and think "Does array_map take the array first, or the
callback?" Because there isn't a good rule of thumb, each function has
to be remembered or looked up individually.
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?"
With namespace, user may choose. We don't force users to *new* or
*old* way.
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.
If we care about confusion, we may change API only with major release
to minimize it.
I can't imagine an API change of that sort being even considered outside
of a major release.
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?
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.
Coding standards are unlikely to accept a mixing of old and new styles
in one project, and bulk conversion of existing code is only possible if
you drop support for older PHP versions. So in order to adopt the new
functions at all, programmers would have to learn both APIs, and
remember the differences between them when switching projects. More
likely, they would simply carry on using the old functions even in new
projects, because the benefit of a slightly better parameter order here
and there wouldn't be worth the cost of learning it.
Further, if a magic ini setting could change which set of functions is
in scope, then distributing code libraries becomes a nightmare. Some
libraries include code to work around the ability to overwrite strlen()
with mb_strlen(), meaning there's no safe function for getting the
number of bytes in a string, and this would be much more far-reaching.
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.
But even then, there is a possibility of a schism in the language, with
some projects opting to stick to compatible, familiar, functions and
others moving to the modern-looking, redesigned, API. And that's
definitely not something I want to see.
Regards,
--
Rowan Collins
[IMSoP]
