Re: Re: [VOTE] Voting opens for str_starts_with and ends_with functions

  106169
July 8, 2019 13:05 andrewgrom@rambler.ru ("Andrew Gromov")
> Please don't switch behaviours via flags: separate names and > implementations are much clearer and much simpler to follow. > > Yes, you will have multiple variations, but that's fine.
It is depends of preferences. In my opinion, create new function for every possible situation is more worse then use flags. Python str.startswith(prefix[, start[, end]]) -> bool C# public bool StartsWith (string value, bool ignoreCase, System.Globalization.CultureInfo culture); public bool StartsWith (string value, StringComparison comparisonType); JS str.startsWith(searchString[, position]) Kotlin fun String.startsWith(prefix: String, startIndex: Int = 0, ignoreCase: Boolean = false): Boolean R startsWith(str, pattern, trim=FALSE, ignore.case=FALSE) Scala startsWith[B](that: GenSeq[B], offset: Int): Boolean Golang, java, C++, Ruby, Swift have simples syntax, like string.startsWith(prefix) C#, Kotlin, R uses flag for ignore case. Anyway, I can't find language from various TOP-lists where present separate function for case insensitive operations. Another note - I see that many languages provide “start_index” parameter for start_with functions. So… As I say - this is good rfc in perspective, but more discussion is needed.
  106170
July 8, 2019 13:20 cmbecker69@gmx.de ("Christoph M. Becker")
On 08.07.2019 at 15:05, Andrew Gromov wrote:

>> Please don't switch behaviours via flags: separate names and >> implementations are much clearer and much simpler to follow. >> >> Yes, you will have multiple variations, but that's fine. > > > It is depends of preferences. > > In my opinion, create new function for every possible situation is more > worse > then use flags. > > > > Python > > > str.startswith(prefix[, start[, end]]) -> bool > > > > C# > > > public bool StartsWith (string value, bool ignoreCase, > System.Globalization.CultureInfo culture); > > > public bool StartsWith (string value, StringComparison comparisonType); > > > > JS > > > str.startsWith(searchString[, position]) > > > > Kotlin > > > fun String.startsWith(prefix: String, startIndex: Int = 0, ignoreCase: > Boolean = > false): Boolean > > > > R > > > startsWith(str, pattern, trim=FALSE, ignore.case=FALSE) > > > > Scala > > > startsWith[B](that: GenSeq[B], offset: Int): Boolean > > > Golang, java, C++, Ruby, Swift have simples syntax, like > string.startsWith(prefix) > > > > C#, Kotlin, R uses flag for ignore case. > > > Anyway, I can't find language from various TOP-lists where present separate > function for case insensitive operations. > > > Another note - I see that many languages provide “start_index” parameter > for > start_with functions. > > > So… As I say - this is good rfc in perspective, but more discussion is > needed.
FTR, there is already substr_compare(). Thanks, Christoph
  106172
July 8, 2019 13:53 claude.pache@gmail.com (Claude Pache)
> Le 8 juil. 2019 à 15:20, Christoph M. Becker <cmbecker69@gmx.de> a écrit : > > FTR, there is already substr_compare().
`substr_compare()` (as well as `strncmp()` which I am currently using in lieu of `str_starts_with()`) forces you to provides the substring and the length of the substring, instead of just the substring: substr_compare('foobarbaz', 'foo', 0, 3) === 0 strncmp('foobarbaz', 'foo', 3) === 0 str_starts_with('foobarbaz', 'foo') —Claude
  106176
July 8, 2019 14:35 zeev@php.net (Zeev Suraski)
On Mon, Jul 8, 2019 at 4:53 PM Claude Pache pache@gmail.com> wrote:

> > > Le 8 juil. 2019 à 15:20, Christoph M. Becker <cmbecker69@gmx.de> a > écrit : > > > > FTR, there is already substr_compare(). > > `substr_compare()` (as well as `strncmp()` which I am currently using in > lieu of `str_starts_with()`) forces you to provides the substring and the > length of the substring, instead of just the substring: > > substr_compare('foobarbaz', 'foo', 0, 3) === 0 > strncmp('foobarbaz', 'foo', 3) === 0 > str_starts_with('foobarbaz', 'foo')
Explaining my 'no' vote (I was quite undecided on it). Generally, I think it's a Good Thing to have startsWith/endsWith functions in PHP. However, several things made me eventually vote 'no' on this proposal at this point in time: 1. I'm still hopeful that we would one day clean up the global namespace by creating a new set of namespacecd functions that would be consistent in naming, semantics and argument order. It feels wrong to add more to the mess right now... 2. Unless I'm mistaken, these functions introduce a new kind of notation for case insensitivity that we don't presently have in PHP (_ci()). Maybe it's a good option, but having a new 3rd or 4th notation feels wrong. 3. Given one can relatively easily (if not as elegantly) use substr_compare() to implement startsWith()/endsWith(), the added value doesn't appear to me to be worth the downsides. Zeev
>
  106179
July 8, 2019 16:52 narf@devilix.net (Andrey Andreev)
Hi,

On Mon, Jul 8, 2019 at 4:54 PM Claude Pache pache@gmail.com> wrote:
> > > > Le 8 juil. 2019 à 15:20, Christoph M. Becker <cmbecker69@gmx.de> a écrit : > > > > FTR, there is already substr_compare(). > > `substr_compare()` (as well as `strncmp()` which I am currently using in lieu of `str_starts_with()`) forces you to provides the substring and the length of the substring, instead of just the substring: > > substr_compare('foobarbaz', 'foo', 0, 3) === 0 > strncmp('foobarbaz', 'foo', 3) === 0 > str_starts_with('foobarbaz', 'foo') >
The existence of substr_compare() and strncmp() is also my main motivation for voting No, though I also share Zeev's reasoning. You're right that the 2 already existing functions are a bit less convenient to use, but the RFC doesn't even try to make a case for that, so how do we know this was even considered? While I'm not against having more than one way of doing things, I do think we need a compelling enough reason to add a third way of doing the same thing and here we don't even have an attempt to convince us. Cheers, Andrey.
  106204
July 10, 2019 10:20 claude.pache@gmail.com (Claude Pache)
> Le 8 juil. 2019 à 18:52, Andrey Andreev <narf@devilix.net> a écrit : > > Hi, > > On Mon, Jul 8, 2019 at 4:54 PM Claude Pache pache@gmail.com <mailto:claude.pache@gmail.com>> wrote: >> >> >>> Le 8 juil. 2019 à 15:20, Christoph M. Becker <cmbecker69@gmx.de> a écrit : >>> >>> FTR, there is already substr_compare(). >> >> `substr_compare()` (as well as `strncmp()` which I am currently using in lieu of `str_starts_with()`) forces you to provides the substring and the length of the substring, instead of just the substring: >> >> substr_compare('foobarbaz', 'foo', 0, 3) === 0 >> strncmp('foobarbaz', 'foo', 3) === 0 >> str_starts_with('foobarbaz', 'foo') >> > > The existence of substr_compare() and strncmp() is also my main > motivation for voting No, though I also share Zeev's reasoning. > > You're right that the 2 already existing functions are a bit less > convenient to use, but the RFC doesn't even try to make a case for > that, so how do we know this was even considered? While I'm not > against having more than one way of doing things, I do think we need a > compelling enough reason to add a third way of doing the same thing > and here we don't even have an attempt to convince us. > > Cheers, > Andrey.
The current existing solutions (using `substr()`, `strncmp()`, `substr_compare()`, `preg_match()` or whatever) are sufficient—and may even look elegant—if you use them once in a blue moon. But if you happen to use them frequently, you’ll find soon that they are cumbersome and error-prone compared to the prospective `str_starts_with()` and `str_ends_with()`. Concretely: * Each time I write `strncmp($foo, "bar", 3) === 0`, I spend a few seconds to double-check the number of bytes in "bar". * Not later than yesterday, I spent one minute in order to find why `substr_compare($file, ".css", -3) === 0` didn’t do what I meant. Note also that the alternative `substr($file, -3) === ".css"` suffers from the same issue, and that the alternative `preg_match('/\\.css$/', $file)` requires you to not forget to escape special characters. Checking whether a string begins, respectively ends, with some substring is a relatively common task for some programmers. The issue is that, although they have already plenty of ways to do that, none of them is natural and all of them have issues. But indeed, the RFC text fails to discuss the various existing alternatives and their downsides. —Claude