Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84412 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 19951 invoked from network); 7 Mar 2015 18:39:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Mar 2015 18:39:47 -0000 Authentication-Results: pb1.pair.com smtp.mail=rowan.collins@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=rowan.collins@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.169 as permitted sender) X-PHP-List-Original-Sender: rowan.collins@gmail.com X-Host-Fingerprint: 209.85.212.169 mail-wi0-f169.google.com Received: from [209.85.212.169] ([209.85.212.169:38486] helo=mail-wi0-f169.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 66/C3-29230-1F54BF45 for ; Sat, 07 Mar 2015 13:39:46 -0500 Received: by widex7 with SMTP id ex7so10046556wid.3 for ; Sat, 07 Mar 2015 10:39:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=tuFfyzQHVa1U2l1FXfnGSMrMFmvrzC/gk81aQVpjSRg=; b=rEC30TyqGBl9Rk9GK4L45GWTA/lnb5AjdqNXzRIdSRPNiSZKi7vJZQ7zO16z9RfZAf ZZEh+AZfx885lcXmbExWFG5gW7f3emNxSvrJQkteJfr6EgI9uxeF7dTGwtsI3oeXwLA8 YY8vT9lp8o5lvdKoXfHYTiPiUqch6P6h39Muo5QYCVFFBkPFKvJZtfFzkbG6pb9lkOf4 5LQ9K18x2K0VEPT1RJEv/kl2o509kXrNfWtPz7nxcQUFeOOeVdTgGgMsJ4Sce849lXJg cByrdWzTEbg9xz7Lhx0CjAy8I/pFvK7UVrVSfmExM683BE/mT2Vsp7uModtP6Apskvqe vcsg== X-Received: by 10.180.90.38 with SMTP id bt6mr44503550wib.46.1425753583335; Sat, 07 Mar 2015 10:39:43 -0800 (PST) Received: from [192.168.0.5] (cpc68956-brig15-2-0-cust215.3-3.cable.virginm.net. [82.6.24.216]) by mx.google.com with ESMTPSA id ub1sm20383352wjc.43.2015.03.07.10.39.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 Mar 2015 10:39:41 -0800 (PST) Message-ID: <54FB45D6.3040803@gmail.com> Date: Sat, 07 Mar 2015 18:39:18 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "internals@lists.php.net" 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> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Consistent function names From: rowan.collins@gmail.com (Rowan Collins) 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. > > > >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]