I think most users of a language take what they are given for basic functions like this instead of always rolling their own. I admit that both of the changes I am suggesting here are minor, but taken together I do think it is a significant and tangible difference (and improvement). I think if you are going by the metric of people rolling their own, then the functions "starts_with" and "ends_with" have probably been implemented many many times by people in various projects (see http://stackoverflow.com/questions/834303/php-startswith-and-endswith-functions, especially notice the solutions using strrev or regex searching). However in that previous discuss that Martin linked to, it looks like it was show down because the functions were deemed too trivial. A funny sidenote is that this message (http://marc.info/?l=php-internals&m=121667513510896&w=2) in that previous discussion has the exact bug in it which I mentioned in my bug (if (substr($path, -strlen($extension)) == $extension) is TRUE for $path = '' and $extension = '0').
I guess the core of my argument is the current PHP string functions, which certainly provide all functionality one could want, are not optimized from simplicity or user friendliness. If PHP wants to optimize for the conciseness of the core library, than I understand an argument to keep out functions like this. However, if PHP wants to add in functions that are simpler to use and have more user friendly interfaces, I think it would benefit by adding in a few of the functions mentioned here (slice, ends_with, starts_with). The reason I led with str_slice, is because I think str_slice makes ends_with and starts_with trivial with no potential corner cases, so if I could pick one function to add, I would pick str_slice. -Dan On Wed, Mar 30, 2011 at 3:35 PM, Jevon Wright <je...@jevon.org> wrote: > If substr() really was so bad, then surely we'd see userland > implementations of str_slice() in every project? > > Jevon > > On Wed, Mar 30, 2011 at 7:06 PM, Dan Birken <bir...@gmail.com> wrote: > > My apologizes if I am bringing up a topic that has been discussed before, > > this is my first time wading into the PHP developers lists and I couldn't > > find anything particularly relevant with the search. > > > > Here is a bug I submitted over the weekend ( > > http://bugs.php.net/bug.php?id=54387) with an attached patch that adds a > > str_slice() function into PHP. This function is just a very simple > string > > slicing function, with the logical interface of str_slice(string, start, > > [end]). It is of course meant to replace substr() as an interface for > > string slicing. > > > > I detailed the reasons I submitted the patch in the bug a little bit, but > > the main reason is that I think the substr() function is really overly > > confusing and just not an intuitive method of string slicing, which is > > exceedingly common functionality. I realize we don't want to go around > > adding lots of random little functions into the language that don't offer > > much, but the problem with that is that if we have a function like > substr() > > with an unusual and unintuitive interface, it becomes unchangeable due to > > legacy issues and then you can never improve. I think this particular > > functionality is important enough to offer an updated interface. In the > bug > > I also pointed to two related bugs that would be essentially fixed with > this > > patch. > > > > -Dan > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
