Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94716
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain wkhudgins.info from 46.232.183.69 cause and error)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 26 Jul 2016 17:27:56 -0400
To: David Rodrigues <david.proweb@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
In-Reply-To: <CAEsg9X1BwYdOKfzO_qU2Fesf0sFu+O8+s0cU0kc=_HNY6=Ndvg@mail.gmail.com>
References: <2a035597d443afb282e374aead55319d@wkhudgins.info>
 <CAEsg9X1BwYdOKfzO_qU2Fesf0sFu+O8+s0cU0kc=_HNY6=Ndvg@mail.gmail.com>
Message-ID: <e013009202e3cd86d10c24d737627f0e@wkhudgins.info>
User-Agent: Roundcube Webmail/1.1.4
Subject: Re: [PHP-DEV] RFC Karma Request
From: will@wkhudgins.info

Thanks for replying David.

Thanks for the questions, its good to elaborate on things some. I'll 
address each question here:

1. No, I guess this is my first time reaching out to the community. I 
had gone with str_begins and str_ends because it fit some of the current 
naming approaches. I could see an argument for strstarts/strends, 
strbegins/strends, or startsWith/endsWith. I'm flexible with the exact 
naming.

2. I don't think performance-wise it would be a big improvement over 
using strpos, preg_match, or substr. However, I think it might be an 
improvement readability-wise. Right now people either use somewhat 
confusing code, like strpos or substr, or they implement their own 
user-defined str_starts function. I think the benefit in terms of 
readability and usability justifies the addition of two new functions to 
the namespace.

3. This functionality is doable with the current implementation. 
However, part of the goal of languages or tools is to make it easy to do 
common, routine tasks. Python, Java, Ruby, C# and JavaScript all provide 
this functionality. So I am sure people would find it useful in PHP.

4. Right now, the way I have it implemented, it is case-sensitive. If 
people wanted, it could be implemented to take an optional boolean 
parameter called case_sensitive which defaults to true. I could make 
that change pretty easily, if I did that the function headers would be:

boolean str_starts (string $str , str $search_value [, bool 
$case_sensitive = true ] )
boolean str_ends (string $str , str $search_value [, bool 
$case_sensitive = true ] )

I like the idea of doing that instead of having separate, 
case-insensitive, functions because it helps keep the name space less 
cluttered.

I hope this has provided some helpful information. Please get back with 
me with your thoughts.

Thanks,
Will

On 2016-07-26 16:09, David Rodrigues wrote:
> Questions:
> 
> 1.
> Have you talked with this list about the terms of you suggestions?
> (like str_begins, str_starts, strstarts, strbegins, str_ends,
> strends...)
> Is yes, sorry, I do not received this topic before.
> 
> 2.
> There some valid performance advantage over strpos()?
> 
> 3.
> And about the "market" for this new function?
> I mean, about users really need a new function like it on core.
> 
> 4.
> And about the case sensitiblity?
> Should have some function like stribegins() or will be an argument?
> 
> In general, I like this implementation, but I like to know about you
> in this questions.
> I don't know the policy about implements new functions on "str 
> namespace".
> 
> Thanks!
> 
> 2016-07-26 15:41 GMT-03:00  <will@wkhudgins.info>:
>> Hello,
>> 
>> I would like to submit an RFC for adding a str_begins and str_ends 
>> function,
>> in relation to https://bugs.php.net/bug.php?id=67035 and
>> https://bugs.php.net/bug.php?id=50434. I've added those functions on 
>> my
>> local PHP copy. I would like to make an RFC and a PR for adding it to 
>> the
>> core PHP copy.
>> 
>> Thanks,
>> 
>> Will
>> 
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>