Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84421 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 48955 invoked from network); 8 Mar 2015 01:16:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Mar 2015 01:16:35 -0000 Authentication-Results: pb1.pair.com smtp.mail=yohgaki@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=yohgaki@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.45 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.218.45 mail-oi0-f45.google.com Received: from [209.85.218.45] ([209.85.218.45:43243] helo=mail-oi0-f45.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 24/00-48254-2F2ABF45 for ; Sat, 07 Mar 2015 20:16:34 -0500 Received: by oibg201 with SMTP id g201so23774889oib.10 for ; Sat, 07 Mar 2015 17:16:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=JF2t+gQAhFWTlr6tbJ5f+fkBng+PNaoqaxJnF2ocag8=; b=OabAgFlOhPjoOUQc6usRT3o19nI7iP2RKKXfJLaYaJR+CNTzjy3f+HF3H4DV9gbxY4 yAEdHeSkzJTq+zNAH5pKholoPhyHBlJOHHcKyYWQwMly48OeMf0WIs6GRisGuRj6SEYh +o6b0Rji6VCrlp1hFJtS3H5I7APL1BRoPUWfW/C6RGkCgDBng1dAGi3mSMQ4c4wlMyi+ wx3GC6mdQqgoC6HSX9Rrfdgq3M9mIRwcsuR6XFJqvsUUq/tAWXNGGyAVVDDEcewPWKoV WSVFFNAWpJdVeIXp6vLIvQyJtwE6bzQPvGBvmpp1E3UnaWacY5f1z/w3gP/kMLJ6FC/a 8BHg== X-Received: by 10.202.52.215 with SMTP id b206mr15515497oia.31.1425777391284; Sat, 07 Mar 2015 17:16:31 -0800 (PST) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.202.58.2 with HTTP; Sat, 7 Mar 2015 17:15:51 -0800 (PST) In-Reply-To: <54FB45D6.3040803@gmail.com> References: <1FCB68B8-3E55-4B5D-B805-9D92D848A3A1@gmail.com> <5D8591E2-5AE6-4B4C-AAE0-3D15523410AC@gmail.com> <54F83C4D.1020206@gmail.com> <54F8BF67.6080600@gmail.com> <848D3C19-DE29-4E5F-9B23-D87D3F4A9365@gmail.com> <54FB45D6.3040803@gmail.com> Date: Sun, 8 Mar 2015 10:15:51 +0900 X-Google-Sender-Auth: FqvyUe-5n16g_Pz0vG6-_IEJPQc Message-ID: To: Rowan Collins Cc: "internals@lists.php.net" Content-Type: multipart/alternative; boundary=001a113cd412efb6af0510bcaaea Subject: Re: [PHP-DEV] Consistent function names From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a113cd412efb6af0510bcaaea Content-Type: text/plain; charset=UTF-8 On Sun, Mar 8, 2015 at 3:39 AM, Rowan Collins wrote: > On 07/03/2015 01:30, Yasuo Ohgaki wrote: > >> Hi Rowan, >> >> On Fri, Mar 6, 2015 at 8:50 AM, Rowan Collins > > wrote: >> >> On 5 March 2015 22:05:05 GMT, Yasuo Ohgaki > > wrote: >> >Hi Rowan, >> > >> >On Fri, Mar 6, 2015 at 5:41 AM, Rowan Collins >> > >> >wrote: >> > >> >> Yasuo Ohgaki wrote on 05/03/2015 20:20: >> >> >> >>> Hi Arvids, >> >>> >> >>> On Thu, Mar 5, 2015 at 9:32 PM, Arvids Godjuks >> > >> >>> > >> wrote: >> >>> >> >>> 2015-03-05 13:49 GMT+02:00 Pierre Joye >> >> >>> >>: >> >>> > >> >>> > >> >>> > 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 >> . 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. > I agree. You are right. The cost of introducing new names disappears over time. The cost of having inconsistent name accumulates. > > > > >> >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. > Only because old names/parameter order is inconsistent, making old function names deprecated/removed is not a good idea. IMO. It should be available as valid/official name/function for a long time if it is ever removed/deprecated. > > > >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. > Then we may be better to declare deprecation of ArrayObject now. > > 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. > I agree that there will be confusions in short term. We have very fast release cycle, PHP 5.6 is only supported for 3 years from now. Instead of measuring cost of short term, long term cost that accumulates should be considered. PHP will introduce new way of programming, including OO, why do you care much about 3rd party documents? They have to rewrite documents for new PHP anyway. Old functions should remain forever or very long term unless there is very good reasons to deprecate/remove. Users don't have to rewrite code only for new names. > > >> >> 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. > The change is about "consistency". Many users complain about it for a long time. New API should have consistent API as well as old API, IMHO. We keep procedural APIs forever, right? Why not clean it up? Older PHP became unmaintained version in 2 years after new PHP release. I think it's short. > >> 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. > Users don't have to rush into new names. It's OK for not adopting new names in short term at all. Old names/functions are valid names/functions. I think it is enough if users use new names mostly decades later. > > > 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. > We have very short release cycle. 2 years later after new release, old PHP became obsolete. Distributors maintains older PHPs, it's users choice to write compatible code and how to write compatible code will be documented well in our manual, as well as how to write new OO API for new PHPs. > >> 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. > Many languages support creating whole new function/class names including PHP. We can have strlen() which returns string length rather than bytes with current namespace. To find out what really happens on function call, we need to check "namespace". I don't see much difference between default namespace by INI and namespace used in script. Both are the declaration of namespace to be used. I agree that adding place to look will be additional work. > > > >> Even without such feature, we may do >> >> PHP FizzBuzz http://3v4l.org/KFRj6 >> > $__=$_('$__,$____',' >> $_ = !""; >> $_ = +""; >> $___ = $_ + $_ + $_; >> $_____ = $___+$_+$_; >> $$_ ="|@@@"^":)::"; >> $$_ = "|]@@"^">(::"; >> $___ = "]]).]:"^"-/@@)\\\"; >> $___(($__%($_ . $_____)?$__%$_____?$__%$___?$__:$$_:$$_:$$_.$$_)." >> "); >> $__- ($_ . $_ . $_) && $____($__+!"",$____); '); >> $__(!'',$__); >> > > > I have no idea what this has to do with anything. > Just an example that PHP allows to write extremely hard to read code already. > > > >> 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. > I think this is the root of our opinion differences. I would like to keep/maintain legacy procedural functions forever. You would like to replace/remove legacy procedural functions by OO like API if it's possible. > > > 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. > Introduction of consistency has it costs. I wouldn't deny it even if it's short term costs. However, keeping inconsistency has it costs also. It's long term costs that never disappears as long as it exists. It's obvious choice for me... > >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. > Let's agree to disagree. Otherwise, discussion will be circular. I would like to keep/maintain legacy procedural functions forever. You would like to replace/remove legacy procedural functions by OO like API if it's possible. I estimate cost of inconsistency is long term and huge. You estimate introduction cost of consistent names is huge, even if it's short term cost disappears over time. I don't think users have to rewrite their existing code at all, so no/little confusions. You think users will try to rewrite their existing code, and there is confusions. I know there are unhappy users that PHP has inconsistent procedural functions and I would like to do something for them. You think those unhappy users should adopt new/better APIs and forget about inconsistency. There are some more, but these are main points from my point of view. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --001a113cd412efb6af0510bcaaea--