Hi Larry,
On Tue, Mar 3, 2015 at 8:02 AM, Larry Garfield <la...@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
yohg...@ohgaki.net
