Re: Consistent function names

On 07/03/2015 01:30, Yasuo Ohgaki wrote:

Hi Rowan, On Fri, Mar 6, 2015 at 8:50 AM, Rowan Collins <rowan.collins@gmail.com <mailto:rowan.collins@gmail.com>> wrote:

    On 5 March 2015 22:05:05 GMT, Yasuo Ohgaki <yohgaki@ohgaki.net
    <mailto:yohgaki@ohgaki.net>> wrote:

Hi Rowan, On Fri, Mar 6, 2015 at 5:41 AM, Rowan Collins

    <rowan.collins@gmail.com <mailto:rowan.collins@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.godjuks@gmail.com <mailto:arvids.godjuks@gmail.com>

<mailto:arvids.godjuks@gmail.com

    <mailto:arvids.godjuks@gmail.com>>> wrote:

    2015-03-05 13:49 GMT+02:00 Pierre Joye

<pierre.php@gmail.com <mailto:pierre.php@gmail.com>

<mailto:pierre.php@gmail.com <mailto:pierre.php@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]