Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:94808 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 78038 invoked from network); 3 Aug 2016 01:15:54 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Aug 2016 01:15:54 -0000 Authentication-Results: pb1.pair.com smtp.mail=will@wkhudgins.info; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=will@wkhudgins.info; sender-id=unknown Received-SPF: error (pb1.pair.com: domain wkhudgins.info from 23.83.209.21 cause and error) X-PHP-List-Original-Sender: will@wkhudgins.info X-Host-Fingerprint: 23.83.209.21 bongo.birch.relay.mailchannels.net Received: from [23.83.209.21] ([23.83.209.21:25631] helo=bongo.birch.relay.mailchannels.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id FC/81-00814-8C541A75 for ; Tue, 02 Aug 2016 21:15:52 -0400 X-Sender-Id: asmallorange|x-authuser|will@wkhudgins.info Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id E4CA8A11D4; Wed, 3 Aug 2016 01:15:48 +0000 (UTC) Received: from krieger.asoshared.com (ip-10-229-2-62.us-west-2.compute.internal [10.229.2.62]) by relay.mailchannels.net (Postfix) with ESMTPA id 463E6A0A81; Wed, 3 Aug 2016 01:15:48 +0000 (UTC) X-Sender-Id: asmallorange|x-authuser|will@wkhudgins.info Received: from krieger.asoshared.com ([TEMPUNAVAIL]. [10.21.150.52]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.7.4); Wed, 03 Aug 2016 01:15:48 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: asmallorange|x-authuser|will@wkhudgins.info X-MailChannels-Auth-Id: asmallorange X-MC-Loop-Signature: 1470186948653:1380470192 X-MC-Ingress-Time: 1470186948652 Received: from [::1] (port=59531 helo=krieger.asoshared.com) by krieger.asoshared.com with esmtpa (Exim 4.87) (envelope-from ) id 1bUkmc-0004X0-GI; Tue, 02 Aug 2016 21:15:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 02 Aug 2016 21:15:42 -0400 To: Yasuo Ohgaki Cc: David Rodrigues , Sara Golemon , PHP internals In-Reply-To: References: <8442f1fa5544b2ca03e7cebbc64e8e5c@wkhudgins.info> Message-ID: X-Sender: will@wkhudgins.info User-Agent: Roundcube Webmail/1.1.4 X-AuthUser: will@wkhudgins.info Subject: Re: [PHP-DEV] RFC Posted for str_begins and str_ends functions From: will@wkhudgins.info On 2016-08-02 18:44, Yasuo Ohgaki wrote: > Hi David, > > On Tue, Aug 2, 2016 at 10:36 AM, David Rodrigues > wrote: >> Sara Golemon wrote: >>> Feeling "meh" on it (neither for nor against), but I would consider >>> consistency with other str*() functions by making case-insensitivity >>> live in separate functions rather than as a parameter. e.g. >>> str_begins(), str_ibegins(), str_ends(), end_iends() >> >> I guess that "i" isn't appliable when it have slashes. >> In this case, functions should be: strbegins, stribegins, strends, >> striends. >> In all case, I think that is better a third parameter and keep >> underlined. > > This is difficult issue. > String function names are inconsistent currently. > It is better to stick to CODING_STANDARDS naming convention for new > function names. Therefore, new string functions are better to be named > str_*() unless they are too strange. > > e.g. > http://php.net/manual/en/function.str-replace.php > http://php.net/manual/en/function.str-ireplace.php > > I would like to fix function name inconsistencies by having aliases in > near future. > https://wiki.php.net/rfc/consistent_function_names > > It might be okay to have "s" in function names, but if we want to be > consistent, > > str_replace -> str_replaces > str_ireplace -> str_ireplaces > > IMO, following names are better for consistency. > > str_begin > str_ibegin > str_end > str_iend > > In addition, str_replace() has seach_value at first, so signature might > be > > boolean str_begin(string $search_value, string $str, [boolean > $case_sensitive = true]) > boolean str_end(string $search_value, string $str, string > $search_value [boolean $case_sensitive = true]) > > However, strstr() (and other str functions without "_". e.g. > strpos/stripos/strrpos/strripos) has search_value as the 2nd > parameter. If we follow this format, current signature is fine. > > It may be better sort out and fix consistency issues first, then add > new functions. Otherwise, we may introduce more consistency issues. > > Regards, > > BTW, having "i" is more readable. > > str_ibegin("searchthis", $str); > is more readable than > str_begin("seachthis", $str, TRUE); > as programmer does not have to know that's the TRUE means. > It's small thing, but small things add up. > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net Everyone has raised important considerations. For me, the most important thing is maintaining consistency with the existing PHP string library. I do not want these functions to feel "tacked" on, as if they were haphazardly added to PHP. If these functions are added to the language, it should feel as if they have always been a part of the language (even if they haven't been). This consistency is important in order to ensure these functions ADD to PHP instead of just cluttering it up. Having separate functions for case sensitivity makes sense, that is much more consistent with the existing string library. I think the proposal should be amended to separate those two functionalities. I think like having an "s" at the end of the function names reads better, but omitting the "s" fits better with the existing function names and does not read bad. Therefore, I am in favor of dropping the "s". As far as str_begin vs strbegin, I think str_begin is more readable. Therefore, I think it would be better to implement: boolean str_begin(string $search_value, string $str) boolean str_ibegin(string $search_value, string $str) boolean str_end(string $search_value, string $str) boolean str_iend(string $search_value, string $str) This is much more consistent with the existing string library. Regards, Will