Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84446 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 53787 invoked from network); 8 Mar 2015 22:43:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Mar 2015 22:43:14 -0000 Authentication-Results: pb1.pair.com header.from=rowan.collins@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=rowan.collins@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.46 as permitted sender) X-PHP-List-Original-Sender: rowan.collins@gmail.com X-Host-Fingerprint: 74.125.82.46 mail-wg0-f46.google.com Received: from [74.125.82.46] ([74.125.82.46:39335] helo=mail-wg0-f46.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 0C/E0-44738-080DCF45 for ; Sun, 08 Mar 2015 17:43:13 -0500 Received: by wghn12 with SMTP id n12so16965169wgh.6 for ; Sun, 08 Mar 2015 15:43:09 -0700 (PDT) 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=IVWABQ3JvD31MF9njLofjj0xNafDAIwE3kQSMP3r/Q4=; b=yWoFcIwY4Z2Kjnei3e2kAq8ixgNsZGFM96icvxy5SuKioIAsVgh1nYQU8n4/QxC9Ud RGdyT2wfcMX80hobRCKC3pzegsxn1TpIlLnOdD3+NHzX4WD4+gEuYngF51JWXPmwI9xA Wa7dt3Cq8oK52jN6FVyPShFR7E9xx2ZI3df4spSxczwEKMEHzi8g1CxOKBxBLGCzdSKp 5SiCN2yXirewBY85ZB5ZKbUumUTVm+sMqpOOyloWTgpMgYWCnIfmNINBrrYDRj0tx7Bt PVESKclVYo4UQa9jzHzJmOI1RkF3bIR1Gyrs2sYCnLOkILtZ8GXxR+QnlV5dxIs3dAYf TVSA== X-Received: by 10.180.91.111 with SMTP id cd15mr9009681wib.75.1425854589673; Sun, 08 Mar 2015 15:43:09 -0700 (PDT) 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 uc18sm12866297wib.0.2015.03.08.15.43.08 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Mar 2015 15:43:08 -0700 (PDT) Message-ID: <54FCD063.4040300@gmail.com> Date: Sun, 08 Mar 2015 22:42:43 +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> <54FB45D6.3040803@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 08/03/2015 01:15, Yasuo Ohgaki wrote: > > On Sun, Mar 8, 2015 at 3:39 AM, Rowan Collins > wrote: > > 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. You've said this a couple of times, but I'm not sure what you mean. What is the cost which is accumulating in the current situation, and how will your proposal stop or reverse this accumulation? > > > >My proposal only requires simple replace. [...] > > > > 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() { ... } > > > 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. Can you please try to respond to the actual points I make, rather than repeating the same ones? You said changing names would be a "simple replace"; I pointed out that it would be more complicated than that (automatable, but not as trivial as find-and-replace in a text editor). This has nothing to do with parameter order, and nothing to do with the old names being removed - just that, if people want to make use of your new function names, they will need a tool to update their code. > 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. No, because it probably still has its uses, and nobody is being encouraged to use it in a way that will interfere with our ability to create "scalar methods" later. An important point you may have missed is that some of the proposals around methods on scalar values don't really propose turning the values into objects, just adding some syntactic sugar to the language so that 'foo'->toUppercase() is a way of writing strtoupper('foo'). > 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. If only it were true that "not supported" meant "nobody cares about". AFAIK, Wordpress is still actively supporting PHP 5.2, which has been unsupported for over 4 years already. The time scale you need to worry about is how long until people start using your new names, and how long after that until they use the old ones rarely enough that people don't need to learn them anyway. > 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. Why do I care about third parties? Because they are the backbone of the language. The language is not you and me debating its future on a single mailing list, it's thousands of people all over the world actually using it. > 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. But the old API already isn't consistent, and unless you remove all the current function names, it will *never* be consistent, because those names will be there, inconsistently. > 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. This is basically the reasoning that led to the Y2K bug: "if we wait long enough, people won't be looking at this old code, they'll have replaced it all. It turns out, code tends to proceed by evolution not revolution, so however long you wait, there will still be the same reasons not to switch over to the new names. > 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. Yes, it's not so much that it's not *possible* right now, as that it's not explicitly *encouraged*. If the authors of Symfony decided they were going to write a function called Symfony\replacement\strlen and "use function" it at the top of every file in their distributed code and coding guidelines, it would not be a popular move. Using namespace imports to alter behaviour as a hack around BC concerns means explicitly encouraging people to do something that makes their code harder to read. > 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. I'm going to say this one more time, and in a very short sentence, in the hope that you'll actually understand/believe me: I do not see it as a choice between OO and procedural API. > 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 estimate that the cost of introducing new names if fairly large, and fairly long-term. I also take from the phenomenal success of PHP over the last twenty years the knowledge that the cost of the inconsistency is not cripplingly large. > 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. No, I think users *won't* rewrite their existing code, but since they won't, the new functions will simply be unused aliases, and the old functions will remain the de facto "real" names. More specifically, this is what I see happening if your proposal passes: - Existing projects, both public and private, will debate whether to convert their code to the new names. Most will see little benefit in doing so. Many will maintain compatibility with extremely old versions of PHP, and be basically unable to do so. - Coding standards will be forced to choose which names to use; because it's not obvious looking at a name whether it's "old", "new", or "unchanged", they will have to create whole lists of banned function names. - PHP-FIG will debate things at great length, and come to a conclusion that not everyone likes, causing friction in the community. - New contributors will submit patches using the new names to projects whose policies require the old names, and be confused by the comments they get back. - New developers will read through eixsting tutorials and code, including cutting-edge code written to the above standards, and still see the same inconsistencies they see now. - Small projects will adopt the new names, forcing developers to learn both. People used to only the new names will keep having to check the manual to be sure the functions are actually just aliases. - The people who like to find excuses to criticise PHP will look at the situation, and say it proves how awful PHP is. This is, I admit, a pessimistic scenario. But the worst case scenario for *not* changing the names appears to be "people will carry on using PHP, but be a bit annoyed at the naming inconsistencies occasionally, and maybe write blog posts about it; some people will be annoyed enough to choose a different language". Do you have a different worst case scenario that makes you so keen to change the names? Regards, -- Rowan Collins [IMSoP]