Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84327
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.181 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <CAGa2bXa+RyQLuYe72f2m+j5c+YObfPtaOTeknMRU7p3s+96Seg@mail.gmail.com>
References: <CAGa2bXYa5Lz0JqySVSQ+hGfCW-WxxKWvqFtWaZo=OVf+LLsV8A@mail.gmail.com> <54F4E29D.7080501@garfieldtech.com> <CAGa2bXbph51CUHr_G87FL65hSDfLSDHo14Bnke-vaLu7SmH=ZQ@mail.gmail.com> <54F4E93C.80206@gmail.com> <54F4EBEC.2090702@garfieldtech.com> <CAGa2bXaQ0SgLWdv7WCoo_qyOQH=t2Vi_bwpk7qXZDEUk+7S7ew@mail.gmail.com> <54F4F3FC.6060501@fischer.name> <CAGa2bXb-d7A3So8e76=p5qqxrZgLK2B_4RKA1OKg0nHZiw9z6A@mail.gmail.com> <54F4FDFB.8010701@lsces.co.uk> <CAGa2bXZUvJJVDVj-48qpPuMas12fnDigKGcE-r=TK20Sahyi7w@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>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Thu, 05 Mar 2015 08:51:33 +0000
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
CC: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <CEF2AD42-3CE1-489F-8192-D1DC3D8D8698@gmail.com>
Subject: Re: [PHP-DEV] Consistent function names
From: rowan.collins@gmail.com (Rowan Collins)

On 5 March 2015 03:59:00 GMT, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>Hi Rowan,
>
>On Thu, Mar 5, 2015 at 10:16 AM, Rowan Collins
><rowan.collins@gmail.com>
>wrote:
>
>> On 4 March 2015 21:27:53 GMT, Yasuo Ohgaki <yohgaki@ohgaki.net>
>wrote:
>> >We cannot remove all issue at once. We are better to adopt
>incremental
>> >improvement, aren't we?
>>
>> I think this, more than anything else, is where I disagree (having
>been
>> persuaded by arguments in previous discussions). Incremental
>improvements
>> mean having the cost of change multiple times, and the benefit just a
>> promise for the future. It's like living in a building site while
>> rebuilding your house - sometimes necessary, but not what you'd
>choose.
>>
>> If we have two names with no other fixes now, then later a third
>name, or
>> some magic flag, which fixes the argument order and error behaviour,
>then
>> go through and tidy up, we'll end up with a whole flow chart of "if
>you
>> need to support version X, use Y; if you find a tutorial using A,
>replace
>> with B..."
>>
>> Some such change is inevitable - a huge number of tutorials became
>out of
>> date when ext/mysql was deprecated, for instance - but it's not
>something
>> to do "little and often" just to make things "a little bit better".
>
>
>Sounds reasonable. I've updated RFC to note not addressed
>inconsistencies
>explicitly.
>There may be others.
>
>Some of these may be addressed by this RFC.
>
>https://wiki.php.net/rfc/consistent_function_names#unaffected_php_functionality
>-----------------
>Unaffected PHP Functionality
>
>This RFC only addresses inconsistent names. These are the list of
>related
>inconsistencies.
>
>  - Parameter order inconsistency. This may be addressed by “default
>namespace” in other RFC.
>- Return type inconsistency. Most severe inconsistency is “wrong number
>of parameters returns NULL”. This may be addressed by “INI switch” in
>other
>RFC.
>  - Constant name inconsistency.
>- Class and method names. Only “__set_state()” and “create_sid()”
>methods
>are addressed.
>
>Future Scope
>
>  - Use of namespace to clean up global namespace at all.
>  - New APIs that replace old APIs.
>  - Parameter order inconsistency.
>  - Return type inconsistency.
>  - Constant name inconsistency.
>  - Class inconsistency.
>----------------
>
>Functions return NULL for wrong number of parameters is easy one to fix
>without BC.
>We may have INI switch return FALSE for invalid number of parameters.
>
>return_value_consistency=On/Off  ; Returns FALSE when number of
>parameter
>is wrong for module functions.
>
>Parameter ordering issue may be addressed also. Instead of having
>alias, we
>may introduce new functions
>for them. The new function name could be issue, though. If you know
>good
>list of functions have strange
>parameter ordering, I appreciate it.
>
>Parameter ordering issue could be addressed by "default namespace" that
>can
>import functions/classes
>to root namespace. This approach requires more work, but it would be
>cleaner than simply having new
>API. I think this issue would be large enough to be a RFC, though...
>
>Do you have particular suggestions?

You missed my point: doing this but by bit is the worst solution, not the best. One of your suggestions implies that we'll have 3 names for the same function: the one that's existed for 20 years but is a bit awkward; a new alias that fits our/your ideal naming scheme; and another with a namespace prefix which is identical except for argument order. Do you not see that that is going to be really confusing for users, no matter how clever we make the manual?

If we add such functions at all, the answer to "which one should I use and why?" should be more than "whichever one was added most recently (unless you need compatibility)". That's why a radical API like scalar methods, or just a designed from scratch set of functions, is the only sensible way to move forward.

Regards,
-- 
Rowan Collins
[IMSoP]