On 23/08/2014 04:39, Yasuo Ohgaki wrote:
Hi Rowan,
On Mon, Aug 18, 2014 at 12:28 AM, Rowan Collins
<rowan.coll...@gmail.com <mailto:rowan.coll...@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]
