Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84329 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 5489 invoked from network); 5 Mar 2015 09:30:34 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Mar 2015 09:30:34 -0000 X-Host-Fingerprint: 78.217.8.218 gaz43-2-78-217-8-218.fbx.proxad.net Received: from [78.217.8.218] ([78.217.8.218:13443] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 15/90-01843-73228F45 for ; Thu, 05 Mar 2015 04:30:32 -0500 Message-ID: <15.90.01843.73228F45@pb1.pair.com> To: internals@lists.php.net Date: Thu, 05 Mar 2015 10:30:28 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 References: <54F4E29D.7080501@garfieldtech.com> <54F4E93C.80206@gmail.com> <54F4EBEC.2090702@garfieldtech.com> In-Reply-To: <54F4EBEC.2090702@garfieldtech.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Posted-By: 78.217.8.218 Subject: Re: [PHP-DEV] Consistent function names From: gregory@luni.fr (=?UTF-8?B?R3LDqWdvcnkgUGxhbmNoYXQ=?=) Le 03/03/2015 00:02, Larry Garfield a écrit : > 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. > > --Larry Garfield This is, from my point of view, the direction to take. Since version 5.0, PHP is aiming to become a true OOP language. Additionally, lots of projects or frameworks are using OOP style coding (and PSR standards). What is missing today in core PHP API is scalar type hints (which I hope will be integrated soon in PHP7) and object scalars. Object scalars can bring easier management for userland developers, without the need for them to refactor their code eg: - mixing native numeric types with large numbers extensions (BCMath, GMP, or others) - define context-specific strings (managing ascii/utf8/utf16/*type in your encoding* and easy cast between them, and then handling html/sql/console escaping with decorators, ect...). I know this is a sensible point due to PHP6 unicode porting failure, but making a common OOP API for string and mbstring extensions could be an easier way to get the same functionality with less painful work As already said in this thread, Nikita Popov did an extenstion bringing this sort of functionalities (https://github.com/nikic/scalar_objects). There is also the PECL extension for Spl types (http://php.net/manual/en/book.spl-types.php) that could be integrated to the core and used as a base. Finally, this could reopen the subject about casting magic methods : https://wiki.php.net/rfc/object_cast_to_types --Grégory Planchat