Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84491 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 46260 invoked from network); 10 Mar 2015 02:00:29 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Mar 2015 02:00:29 -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.47 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.218.47 mail-oi0-f47.google.com Received: from [209.85.218.47] ([209.85.218.47:36711] helo=mail-oi0-f47.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 54/E0-36114-B305EF45 for ; Mon, 09 Mar 2015 21:00:28 -0500 Received: by oiba3 with SMTP id a3so32967917oib.3 for ; Mon, 09 Mar 2015 19:00:24 -0700 (PDT) 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=WTpxB/RjzyHihiGbuQIaAE/fHYKu7HsmllJlO2cjrqU=; b=lq9M398clD7Va6VOOu0StPmaQYV6+jxpHlJZqvq8WKfkIJ8qCOo2SMxhye0BnY9SEx Y4X7idquPAIzqcdgby3lINz+8QePGR6vuQWET7Xd+ZPjmh/NPWT3eRL3lrC7Ma5DXjfJ rjVXemuO6E8jm7sCUGHO1LVGwkfCYD8VcpQuVR0XQbHkduhKJEMtMs+ItfvKRWS3Tv6k 536RM6s/E4avJrN+B6H5bS+8Xfm9d8dBoeqT3Jt/a/qvKiNsveku3lpMp+jYdMH8kYbU lCXL1JQZpwkOdmVtj3SlMBxDddsDCcZs55SiynLMvr4sKf+4mdrg5BtuCDK8FNaxJOxd P2yA== X-Received: by 10.202.65.8 with SMTP id o8mr22759997oia.113.1425952824653; Mon, 09 Mar 2015 19:00:24 -0700 (PDT) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.202.58.2 with HTTP; Mon, 9 Mar 2015 18:59:43 -0700 (PDT) In-Reply-To: <54FCD063.4040300@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> <54FCD063.4040300@gmail.com> Date: Tue, 10 Mar 2015 10:59:43 +0900 X-Google-Sender-Auth: FKWcMbUxi1dCJOgckseAG4aZCpc Message-ID: To: Rowan Collins Cc: "internals@lists.php.net" Content-Type: multipart/alternative; boundary=001a113ddb5e947de60510e583e7 Subject: Re: [PHP-DEV] Consistent function names From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a113ddb5e947de60510e583e7 Content-Type: text/plain; charset=UTF-8 Hi Rowan, On Mon, Mar 9, 2015 at 7:42 AM, Rowan Collins wrote: > 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? > By introducing consistent names. We have obvious cost for having inconsistent names. People complain/hate it for a long time in past and future. We don't have to reverse it, but make it disappears over time. I understand your point of views that old inconsistent procedural API should be disappeared in the future. However, I cannot agree to make procedural API disappear. > >> >> >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. > Users may use whichever tools they like. I use Perl one liner for this kind of simple search and replace, then check it by git diff. Besides, they don't have to change their code. They may keep using old names as long as they exist. > 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'). > You think legacy procedural should be gone and replaced by OO features preferably. Procedural API is used a lot of codes. I agree that ArrayObject is used by only few codes. Why against to declare legacy ArrayObject deprecation even we will have new OO API? If things are going to be deprecated, we are better to let users know as soon as possible, then implement E_DEPRECATED error. Remove them if it's unneeded at all in the future. Deprecation means removal in the future. We may at least let users know it will be obsolete in near future. 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. > The same argument applies to fresh new OO APIs. > > > > 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. > My RFC is not going to depreciate/remove old inconsistent names. On the other hand, it makes most of standard violating names valid names officially. I fail to see what's wrong for 3rd party document with 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. > I cannot agree "Because we have inconsistent names already, we cannot have new consistent names" argument. What you are suggesting is _not_ to have "is_writable()" because we have "is_writeable()" already. http://php.net/manual/en/function.is-writable.php http://php.net/manual/en/function.is-writeable.php or http://php.net/manual/en/function.disk-free-space.php http://php.net/manual/en/function.diskfreespace.php > 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. > Again. This RFC make function names that are named after IEEE/C library valid names officially. I don't see any relevance with Y2K 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. >> > > > 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. > Feature to import namespace into default "\" namespace is required not only for procedural API but also OO API to adopt namespace for internal functions/classes without any BC. It's very important argument. We may discuss this when there is RFC. 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. > You sounded like it, but I believe this words from now on. > 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. > http://php.net/manual/en/function.is-writable.php http://php.net/manual/en/function.is-writeable.php This kind of change should be adopted ASAP, IMHO. Name inconsistency is just like typo for me. i.e. Keeping it just damages things. Have corrected names and keep old names is the only way to have consistency. 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. > Nothing wrong with it. User may use old names, it's valid names also. > > 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? > The same argument applies to fresh new OO APIs. It's just a matter of targeted PHP version to be supported. There are many things to be considered to decide targeted PHP version other than this RFC. We have many new features/behaviors in newer PHP versions. I'm OK for "agree to disagree", too. However, since you are not willing to make procedural APIs obsolete/deprecate, why don't we agree to "maintain" procedural APIs? Just like http://php.net/manual/en/function.is-writable.php http://php.net/manual/en/function.is-writeable.php Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --001a113ddb5e947de60510e583e7--