Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84204
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.45 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <54F4EBEC.2090702@garfieldtech.com>
References: <CAGa2bXYa5Lz0JqySVSQ+hGfCW-WxxKWvqFtWaZo=OVf+LLsV8A@mail.gmail.com>
 <CAEZPtU41xa1yrLPYn_VHx-axOmuM4_KAa00zwPRhpm5ZLSbQ+Q@mail.gmail.com>
 <CAGa2bXZD1MJojzFu8FwmGKH7gZxpqP7bNUusgQ3YzEpBduCs_g@mail.gmail.com>
 <CAEZPtU6=KY2tzRE8yw6kEdh4SrVJ3uG81XX5yuu0E_63G1HN6g@mail.gmail.com>
 <54F4E29D.7080501@garfieldtech.com> <CAGa2bXbph51CUHr_G87FL65hSDfLSDHo14Bnke-vaLu7SmH=ZQ@mail.gmail.com>
 <54F4E93C.80206@gmail.com> <54F4EBEC.2090702@garfieldtech.com>
Date: Tue, 3 Mar 2015 08:10:15 +0900
Message-ID: <CAGa2bXaQ0SgLWdv7WCoo_qyOQH=t2Vi_bwpk7qXZDEUk+7S7ew@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113a9544901f8505105654e5
Subject: Re: [PHP-DEV] Consistent function names
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a113a9544901f8505105654e5
Content-Type: text/plain; charset=UTF-8

Hi Larry,

On Tue, Mar 3, 2015 at 8:02 AM, Larry Garfield <larry@garfieldtech.com>
wrote:

> On 3/2/15 4:50 PM, Rowan Collins wrote:
>
>> On 02/03/2015 22:36, Yasuo Ohgaki wrote:
>>
>>> I like scalar objects, but it does not resolve that PHP has non standard
>>> function names.
>>> It does not change old names, therefore it's impossible to resolve issue.
>>> This is the reason why I'm proposing while I like scalar object, use of
>>> namespace, etc.
>>>
>>
>> Again, you're contradicting yourself here - you can't say that your
>> mission is to change the old names, rather than offer an alternative,
>> but then also say that the old names will stay around forever. If both
>> names exist, that's exactly what you've created - an alternative.
>>
>> If we're going to have an alternative, let's come up with a creative
>> alternative that actually has an advantage to using it, not a choice
>> between equally cryptic names like "strripos" vs "str_ripos".
>>
>> Regards,
>>
>
> Exactly. If a PHP 7 dev has the option of:
>
> $s = strripos($s, 'a'); // works in PHP 5+
>
> $s = str_ripos($s, 'a'); // works in PHP 7+
>
> Really, what's the advantage of the latter?  Nothing.  It's an extra
> character to type, limits compatibility, and makes my life no easier. It's
> useless, and will just add to the list of things people make fun of PHP for
> instead of reduce it.
>
> Namespacing it is no better:
>
> $s = str\ripos($s, 'a'); // Still useless
> $s = php\str_ripos($s, 'a'); // Still useless
>
>
> Instead, compare:
>
> $s = strripos($s, 'a'); // works in PHP 5+
>
> $s = $s->lastOccurance('a', 0, CASE_INSENSITIVE); // works in PHP 7+
>
> Oh now we're talking!  That's more self-documenting, easier to discover,
> makes chaining string manipulations easier to read, solves the
> needle/haystack issue, and reduces cholesterol.
>
> One is worth the effort of doing.  The other is simply not.
>
> For subsystems that aren't clear scalars, like streams, those need a
> general overhaul for DX, too.  Again, just doubling the number of function
> names adds nothing to the language but confusion, since both versions would
> have to live for at least the next decade.  Offering a substantially better
> alternative does improve the language.  Don't waste your time on marginal
> not-even-improvements.


I would love to have new & clean APIs.

Please think my proposal as legacy API cleanups. Many of candidates will
remain
without CORDING_STANDARSDS confirmed names almost forever. This is what
I would like to improve. If you don't care about legacy stuff cleanups,
please don't
care. The cleanups will not hurt anything, almost.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a113a9544901f8505105654e5--