Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84202 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 17983 invoked from network); 2 Mar 2015 23:02:09 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Mar 2015 23:02:09 -0000 Authentication-Results: pb1.pair.com smtp.mail=larry@garfieldtech.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=larry@garfieldtech.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.25 cause and error) X-PHP-List-Original-Sender: larry@garfieldtech.com X-Host-Fingerprint: 66.111.4.25 out1-smtp.messagingengine.com Received: from [66.111.4.25] ([66.111.4.25:47157] helo=out1-smtp.messagingengine.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id EE/13-14834-0FBE4F45 for ; Mon, 02 Mar 2015 18:02:08 -0500 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 610F920B10 for ; Mon, 2 Mar 2015 18:02:04 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 02 Mar 2015 18:02:05 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=RZB3Xfl0LXj6AXbskJUTPD dE+lI=; b=lHQg9emvPBT42IzWlm5cYTU/f6dA2mAPe1gnsM7hVrJnZap7ZUg7BP 2Bn2WuJDRBzDUq8GC1hgu9tFMsfNTkWQ6Xl+5MwYuqPgUGG2b3aPHcis3X92s4DE brw+mAod26kkdKDLEXjmst+TIDikz8uQXpCzjlMf3JAxADaOXSXzM= X-Sasl-enc: 2D63rmkaOpLURSqFFqMrlOG2JFNMqpWBCqVpEFtp4gbJ 1425337325 Received: from Palantirs-MacBook-Pro-7.local (unknown [63.250.249.138]) by mail.messagingengine.com (Postfix) with ESMTPA id 3EC91C0028C for ; Mon, 2 Mar 2015 18:02:05 -0500 (EST) Message-ID: <54F4EBEC.2090702@garfieldtech.com> Date: Mon, 02 Mar 2015 17:02:04 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: internals@lists.php.net References: <54F4E29D.7080501@garfieldtech.com> <54F4E93C.80206@gmail.com> In-Reply-To: <54F4E93C.80206@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Consistent function names From: larry@garfieldtech.com (Larry Garfield) 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