On 07/03/2015 01:30, Yasuo Ohgaki wrote:
Hi Rowan,
On Fri, Mar 6, 2015 at 8:50 AM, Rowan Collins <rowan.coll...@gmail.com
<mailto:rowan.coll...@gmail.com>> wrote:
On 5 March 2015 22:05:05 GMT, Yasuo Ohgaki <yohg...@ohgaki.net
<mailto:yohg...@ohgaki.net>> wrote:
>Hi Rowan,
>
>On Fri, Mar 6, 2015 at 5:41 AM, Rowan Collins
<rowan.coll...@gmail.com <mailto:rowan.coll...@gmail.com>>
>wrote:
>
>> Yasuo Ohgaki wrote on 05/03/2015 20:20:
>>
>>> Hi Arvids,
>>>
>>> On Thu, Mar 5, 2015 at 9:32 PM, Arvids Godjuks
><arvids.godj...@gmail.com <mailto:arvids.godj...@gmail.com>
>>> <mailto:arvids.godj...@gmail.com
<mailto:arvids.godj...@gmail.com>>> wrote:
>>>
>>> 2015-03-05 13:49 GMT+02:00 Pierre Joye
<pierre....@gmail.com <mailto:pierre....@gmail.com>
>>> <mailto:pierre....@gmail.com <mailto:pierre....@gmail.com>>>:
>>> >
>>> >
>>> > I will say it again a last time, in my opinion only a clean
>API;
>>> > object-like or real object as long as performance is not
>affected is
>>> > the only way I could see to actually solve this problem.
>>> >
>>> > Changing the names, argument order (pointless once we will
>have
>>> named
>>> > arguments, btw) and similar solutions are band aids
solutions,
>>> > confusing at best, terrible at worst. It is pointless to
do it
>after
>>> > almost two decades for some of them.
>>> >
>>> > --
>>> > Pierre
>>> >
>>> > I'm with Pierre here.
>>> Adding aliases is gonna mess up things even more. For
example -
>>> autocomplete will become hard to navigate. It's already quite
>>> lengthy list
>>> a lot of the times and it's easier just to write the whole
>>> function name
>>> sometimes by hand. Adding aliases will make it worse.
>>>
>>>
>>> I agree. Therefore, I'm going to update manual also so that it
>recommends
>>> main function, not aliases. Aliases should be alternative.
>>>
>>> Manual and IDE don't have to list all of them. New manual
lists only
>main
>>> functions, does not have dedicated pages for aliases but
aliases are
>>> mentioned
>>> in main function page as aliases.
>>>
>>
>>
>> You can't fix everyone's IDEs for them. You can't fix all the
>> documentation (tutorials, blogs, Q&As) not hosted on php.net
<http://php.net>. Most of
>> all, you can't fix the thousands of projects already written in PHP
>using
>> the "wrong" function names, most of which will want to *continue*
>using
>> those function names, because that will be internally
consistent, and
>> portable between versions.
>>
>> The problems people are pointing out are not ones that you can
>promise to
>> fix.
>>
>
>The same argument applies to OO API alternative.
>It's impossible update documents/etc to use new OO API as you
>mentioned.
To an extent, yes. Part of the point that I and others are making is
that this is not a simple change to make. Whatever we do to try and
"fix" the current inconsistencies comes at a cost, and we need to be
very careful in justifying that cost.
>
>My proposal only requires simple replace. Even simple replace
would not
>be
>needed since old names work as should be. Users can know what's the
>main
>function by looking up manual.
You have to do at least a bit of code parsing, because you wouldn't want
to change things like echo 'Your site has exploded!'; or function
check_blob_is_in_array_twice() { ... }
So this really comes to the same thing whatever changes we make - people
can either run a converter tool over their code (and create some noise
in the version control history) or you carry on using the old functions
and get no benefit from the change.
>It does not seem new OO API will do better job as it may have
>completely
>different method names and syntax.
Yes, that's why I like it. If someone new to PHP finds a tutorial using
"in_array($foo, $bar)", and one using "array_contains($bing, $bong)",
it's not obvious that these are two names for the same thing, and that
one is deprecated but backwards compatible, and the other is considered
"nicer", but only works in certain versions. Yes, if they check the
manual, they'll find out, but how do they know they need to check the
manual?
If, instead, they find the old tutorial using "in_array($foo, $bar)",
and the new one using "$foo->contains($bar)", they might notice that
there is a different *style* of code going on, and wonder what that's
about. They will then probable find a lot of people talking about
"procedural-style vs OO-style" or similar, and get a hint as to the pros
and cons of each.
That's actually the advantage of an OO-style API - it's really
obvious which set of functions someone else is using, and really
easy to look at the two side by side.
Users will not spend their time cross-referencing every function
they see in a tutorial against the manual to see if it's been
renamed with some extra underscores, and whether the new name has
a different parameter order or error behaviour. But they might
well read an article on how in version X, you can write things
with this different syntax, and they'd instantly see that the old
tutorial they found wasn't using that syntax.
We have ArrayObject.
http://php.net/manual/en/class.arrayobject.php
I'm not a supporter of this class. Both class name and methods are not
good enough. Implementation seems complex overly.
It sounds like you are going to oppose to have improved array classes
and/or array variable OO extension for the same reason.
- Do you oppose to have better array class alternatives because of
ArrayObject?
- Do you think we must stick to this class/methods because it's
already been here for a long time?
- Do you oppose to have array variable object, i.e.
$var_array->sort(), because we have ArrayObject already?
- Do you agree if I object to have new/better OO API by existence of
ArrayObject?
No, no, no, and no. ArrayObject is a rarely-used class allowing users to
have something that's halfway between an array and an object. It was
introduced in PHP 5, but only guaranteed to be available in PHP 5.3
(because distributions could disable the SPL extension by default before
that); the majority of users of PHP have probably never heard of it. It
also can't, and isn't intended to, replace the normal array type, which
is incredibly flexible, and at the heart of many parts of PHP.
Contrast that to, say, in_array(), which has been around for at least 15
years, probably more, and is probably used in about 90% of PHP scripts
written in that time, including thousands which are still maintained, or
publically available to be used as examples by new programmers. Any
argument treating the two as equivalent is a straw man.
>> The paragraph you are replying to says "new API". It does not say
>"pure
>> OO". As I've said before, the relevance of scalar methods is
not that
>> objects are cool and functions are boring; it's that they're
>something new
>> we can design from scratch without worrying about the 20 years of
>legacy
>> the existing API has.
>>
>
>I'm against making procedural API legacy so that someone would not
>propose
>
>"Let's discard legacy, messy and inconsistent procedural API at all"
Again, you bring it back to the assumption that "new API" means
"not procedural any more". I'm not sure how many different ways I
can find of saying that's not the point.
I thought you prefer to have scalar object (including array) rather
than procedural API fix/improvement. I'm lost here. So how would you
like to fix naming mess and parameter miss ordering issue in
procedural APIs? Leave inconsistent procedural functions forever?
As I have said repeatedly, I prefer to have some kind of brand new API,
so that it is really obvious to users that they are using "the new API"
or "the old API", rather than a bunch of minor variations which you can
only learn by studying the manual and remembering which is which. Adding
methods on scalars and arrays (which doesn't necessarily mean making
them objects in any meaningful way) is just a way of achieving that
goal. If someone comes up with a procedural API that feels new and
fresh, I'm all for it; a few changes to the existing API, I'm against.
It's not that it doesn't do enough to keep the API around -
frankly, I can't see those functions going away whatever happens.
It's that it doesn't do enough for people to want to start using
the new functions. Who is going to bother replacing all their
instances of in_array with array_in?
I agree that old functions should be able to use. Old name aliases
should stay forever. Users do not have to rewrite their code with this
RFC. They can use old names as long as they wish. Old codes are not
invalid code, but perfectly valid code.
But if nobody adopts the new functions, all your effort will have been
in vain. If every PHP script was written in complete isolation, used for
a while, and thrown away, a free choice makes sense. But old code
*evolves* into new code, and now more than ever, PHP has an eco-system
of interoperable shared libraries, and people need to be able to read
and contribute to each other's code. For any new names or API to be
successful at all, people have got to WANT to change their code.
So your idea is to leaving behind procedural API inconsistencies
forever and keep as it is?
Either we leave it as it is, because we don't have the time machine
required for the proper fix, or we come up with a creative solution to
the problem, rather than making a few confusing changes.
I used to really like the idea of a namespace with all the new
functions in, and indeed the bulk import/default namespace idea,
but I realised it doesn't really help. You have zero BC, but you
also have a language which is incredibly hard to read, because the
same line of code will do different things based on whether the
file begins with a particular "use" statement. And now, rather
than being confused about whether array_key_exists takes needle
first or second, users have to be confused that it sometimes works
one way, and sometimes the other, depending on which namespace
they're operating in.
I agree. Flexibility comes with its cost. It's possible to write
incredibly hard to read code with Ruby/JavaScript/Scheme/etc.
This is one of the reason why I didn't propose "namespace" use.
Keeping RFC simple is better to discuss targeted issue.
It's not that namespaces would make code hard to read as such. What
would make code hard to read would be having the same function work
differently depending on a setting at the top of the file. You'd be
replacing one kind of inconsistency with another.
Even without such feature, we may do
PHP FizzBuzz http://3v4l.org/KFRj6
<? $_ = ("@]@@]@"^"#/%!)%")._.("@]@@]@@@"^"&(.#))/.");
$__=$_('$__,$____','
$_ = !"";
$$_ = +"";
$___ = $_ + $_ + $_;
$_____ = $___+$_+$_;
$$$_ ="|@@@"^":)::";
$$$$_ = "|]@@"^">(::";
$$___ = "]]).]:"^"-/@@)\\\";
$$___(($__%($_ .
$_____)?$__%$_____?$__%$___?$__:$$$_:$$$$_:$$$_.$$$$_)."
");
$__- ($_ . $$_ . $$_) && $____($__+!"",$____); ');
$__(!'',$__);
I have no idea what this has to do with anything.
I mean that you are approaching this with the enthusiasm of
someone bringing a new idea to the table, and trying to win over
people who've been working on the prioject for years. But the fact
is that this conversation has been had before, many times over,
and it has never been adopted before. You have very little chance
of getting it adopted this time.
You are probably right.
There were roughly 4 groups of people.
1. Inconsistent/legacy procedural API must be replaced by new/better
OO API
2. Do not care consistency and keep it as it is now.
3. Some current names are good enough and should not be removed.
(e.g. IEEE/C lib based names)
4. Consistent naming is important.
1, 2 and 3 are majority. I added IEEE/lib names as a part of PHP
standard names.
There will be more supporters hopefully, but it seems it's not enough.
I would re-word point 1 as "...replaced by new/better API, probably OO
or OO-like". The emphasis is on the new, not the OO, IMHO.
There may be such people, yes. But they are not your main problem
in getting your proposal adopted. Your main problem are two groups:
- those who think it is far too late to change any of this, and
that it's just not worth the hassle for a few minor annoyances
- those who think that it might be justifiable if we can find a
way of making a compelling new set of functions, rather than just
tweaking a few corner cases
Thank you for the analysis. It's reasonable one. I should think how to
persuade them.
Changes are never too late! Especially non destructive change like
this RFC.
Sometimes it really is too late to change something; it's too late to
decide that we don't want $ in front of variables, for instance, not
because it's not a "good" change, but because it would cause huge
disruption, so could only be justified by an even bigger benefit.
"Non destructive" makes it sound like there is no cost; as I have
repeatedly explained, it does have a cost.
>The reason why previous proposals have failed is aggressive OO
>supporter
>rejected "procedural API improvement", isn't it?
No. That is a relatively recent phenomenon, if it's real at all.
The reason previous proposals have failed is that people think the
costs outweigh the benefits.
I saw many "There should be better OO API for them and use them" for
PHP5 discussion also.
I don't understand the reasoning "costs outweigh the benefits". It
sounds like excuse for promoting OO API for me. Use of new OO API
requires new codes/manuals. It's more than aliasing. Cost of having
new name disappears over time while cost of having inconsistent names
accumulate.
I don't know what's hard to understand about comparing costs and
benefits. Yes, there are benefits to having consistent names; we all
agree on that. What we disagree on is the cost of achieving that. It's
not an "excuse for promoting" anything; it's just a difference of
opinion about how enthusiastically everyone will adopt the new names and
thus erode the cost of having both names in use.
>Let's see how it goes by vote. This vote is going to be whether we'll
>take
>direction to pure OO or multi-paradigm.
No, the only vote we can have right now is on the option on the
table, so will be whether it's worth the pain to change things
which have worked this way for twenty years. There is no proposal
on the table for making PHP an OO only language, and I'm not even
sure what such a proposal would look like at this point in time.
PHP is not in imminent danger of death if we leave a handful of
string and array functions with slightly awkward names and
behaviour, so it's not like we've got to choose between two rescue
plans, messing with the functions or jumping into OO.
I get that you find those functions annoying, but not everyone
agrees with you. Maybe I'm wrong and there's a silent majority
willing to push this through, but I would be extremely surprised
if a vote on this was anything other than a landslide "no thanks".
Again. This RFC is not a destructive RFC at all. Good changes are
never too late. Almost all languages does this kind of
maintenance/improvement, even destructive changes like dropping old
syntax/etc.
Unless one is not willing to replace/eliminate legacy and messy
procedural API, I don't understand the reasoning to object to have
consistent names. It's new consistent names that can be used
optionally. Old names are available probably forever.
If after this many e-mails, you really don't understand why, as a matter
of opinion, people think this proposal is too costly, I really don't
know what more I or anyone can say to explain it to you.
I do rename for my codes to keep it consistent all the time. We do
rename PHP internal code to keep it nice and consistent on occasions.
I fail to see why not PHP functions, why not giving users a chance to
use nice and consistent names if users would like to.
Anyway, your opinions to summarize:
- User should use new/better OO API. (And we should focus new OO API
development)
- Inconsistent names should be kept forever.
- This RFC requires existing manual/code rewrites. Therefore, this
RFC does not worth to adopt.
Is this correct? I find a little contradictory opinions here... We
need completely new manuals/codes for new OO API while this RFC does not.
Not quite; my opinions are more like this:
- Inconsistent names of core functions are here to stay whether we like
it or not.
- If we want to create an alternative, it needs to be something radical.
An OO-style API seems the best candidate for that so far suggested.
- This RFC doesn't give existing users any incentive to rewrite all
their code with the new names, but will leave new users even more
confused because they won't know why all the functions have two names,
and why some code uses one and some uses the other. Therefore, it
creates more problems than it solves.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php