Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84370
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.177 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <CAGa2bXbvZbMb5C0RnaDAVTAMK_+9x-BzidXcm9MgoaGmtWK+Zg@mail.gmail.com>
References: <CAGa2bXYa5Lz0JqySVSQ+hGfCW-WxxKWvqFtWaZo=OVf+LLsV8A@mail.gmail.com> <54F5895D.3090002@gmail.com> <CAGa2bXbuNEcvoeeBhkUUEkiHZJFvJTVX=h_JPTLHpMTtgbCokw@mail.gmail.com> <554F0C3F-770F-4694-A5AB-FDC54FCCBF00@gmail.com> <CAGa2bXbDdS=N=JmPwBa1iorx1aJPuo00EfU7bw31cknAxAfDyQ@mail.gmail.com> <1FCB68B8-3E55-4B5D-B805-9D92D848A3A1@gmail.com> <CAGa2bXYrsa7t80qo_9YEiU=ZD4k+KESU3Hn+DiJeVvwgFyyjRQ@mail.gmail.com> <5D8591E2-5AE6-4B4C-AAE0-3D15523410AC@gmail.com> <CAGa2bXa+RyQLuYe72f2m+j5c+YObfPtaOTeknMRU7p3s+96Seg@mail.gmail.com> <CEF2AD42-3CE1-489F-8192-D1DC3D8D8698@gmail.com> <CAGa2bXZDnuE3mKQYD+Sq2=kH=YDXuRQA3o+9wg4v81ZS+h3rLw@mail.gmail.com> <54F83C4D.1020206@gmail.com> <CAEZPtU6ni038E+b0ziAC1b0w=t3gsmBwMjAui4e0sXd8EgbyXQ@mail.gmail.com> <CAL0xaBF7u2h9A5UnVB+-z6SwDtLOVY_qL7B9UGj7w_Lecwct6A@mail.gmail.com> <CAGa2bXa5zER03VrMrtD9aUQ38LK9C_UWU-jbGjzEZUoxbUsSQQ@mail.gmail.com> <54F8BF67.6080600@gmail.com> <CAGa2bXbvZbMb5C0RnaDAVTAMK_+9x-BzidXcm9MgoaGmtWK+Zg@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Thu, 05 Mar 2015 23:50:50 +0000
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
CC: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <848D3C19-DE29-4E5F-9B23-D87D3F4A9365@gmail.com>
Subject: Re: [PHP-DEV] Consistent function names
From: rowan.collins@gmail.com (Rowan Collins)

On 5 March 2015 22:05:05 GMT, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>Hi Rowan,
>
>On Fri, Mar 6, 2015 at 5:41 AM, Rowan Collins <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>> wrote:
>>>
>>>     2015-03-05 13:49 GMT+02:00 Pierre Joye <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. 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.
>
>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.
>
>It does not seem new OO API will do better job as it may have
>completely
>different method names and syntax.


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 really need a new API, that is not crossing paths with the
>old.
>>>     That way
>>>     people can start building stuff on new API's and we could phase
>>>     out the old
>>>     mess, for example: depricate in PHP8, remove in PHP9.
>>>     Stop-gap measures have created enough problems already, or did
>>>     everyone
>>>     suddenly got an amnesia and forgot all the past lessons on the
>list?
>>>
>>>
>>> PHP should be multi paradigm language, not pure OO language.
>>> IMO. Python does good job.
>>>
>>
>>
>> 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.


>We should keep good procedural API forever.
>Procedural API has good set of well defined API such as IEEE 1003.1.
>PHP
>also defines good set of procedural APIs. These APIs do not need
>radical
>changes, but
>only small improvement and adjustment is enough like this RFC proposes.
>(I'll add parameter order issue handling proposal later)
>
>
>>
>>
>>
>>  I finally understand why some of us against this change and suggest
>OO
>>> APIs
>>> as alternative. It's reasonable making procedural APIs a
>>> legacy/unmaintained/
>>> messed up to discard  procedural APIs someday. I'm against it. PHP
>should
>>> be like Python in this regard. IMO.
>>>
>>
>>
>> OK, so let's look at our options to maintain the language as
>> multi-paradigm:
>>
>> 1) Implement piecemeal tweaks to the current API, adding to the
>confusion
>> of users, in the hope that eventually we accumulate enough fixes,
>everyone
>> gets used to them, the old ones die away somehow, and the result is a
>> slightly nicer set of functions, with various awkward compromises
>along the
>> way.
>>
>
>I'm going to adopt your suggestions. One is parameter ordering which
>have
>been issue for a long time. I'll address this issue with this RFC.


Please don't credit me with that suggestion. It comes up just as often as the naming consistency, with just as much lack of support. Hence the bullet on the "mysterious PHP RFC process" blog post requesting that nobody try to put forward an RFC for either of them.



>As I mentioned, small improvements and adjustments would be enough to
>keep
>procedural APIs forever. If my proposal is not good enough to keep
>procedural API for good, please
>suggest what's missing.


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?


>2) Find a way of designing a clean-break new API which is still
>procedural.
>> More than just a namespace, which is basically just some new names
>with \
>> in; and definitely not something where the same code can mean a
>different
>> thing depending on a setting or import at the top of the file.
>Something
>> which will feel fresh, which users will want to start using, and will
>> recognise when they see code using it.
>>
>
>I probably don't understand well what you meant here.
>If we have default namespace to be imported to "\" namespace and user
>could
>choose which names to import, we have zero BC for completely new APIs
>for
>both OO and
>procedural APIs. (We have a beast, constants defined by define(),
>though)


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'm not suggesting radical improvement for procedural APIs. Both PHP
>and
>IEEE procedural APIs are well established. Only small modifications are
>needed, IMO.
>
>
>> I don't what that might look like, but if you have some ideas, that
>is how
>> you will move this discussion forward, with a radical new solution;
>> everything you have said so far are things which have been said over
>and
>> over again before. Come up with something which nobody has thought of
>> before, or take our word for it that everyone who has previously
>proposed
>> this has failed.
>>
>
>What do you mean by "take our word for it that everyone who has
>previously
>proposed this has failed."?


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.


>As I mentioned, there are group of people who would like to "remove
>procedural API completely and make PHP a pure OO language in the
>future". I
>understand the motivation very well. It's possible option. However, I
>don't
>think we have consensus for "removing procedural API completely and
>make
>PHP a pure OO language in the future".


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


>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.


>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".

Regards,
-- 
Rowan Collins
[IMSoP]