Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51758
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=JmpbcGiZf0J1EN3vAr9dBswaeEfcrWC3wFZHdjYyQMf01qpouA1gJpjefvTKrU0nBZ
         T3ejInaPcbpVBFEKyzUVkq9XY6I0ZRmZtl6AXCEK6ur+4Sjsz2PsCtqhY8MMty/S6Lam
         cPdX4u+By/+mW4uDQU42Opu5b018zpZGUk+8A=
MIME-Version: 1.0
In-Reply-To: <AANLkTikyVb3bPXNtvTOq5tQ8iB_SfzCFBb94tqoySPKD@mail.gmail.com>
References: <AANLkTinWgyueX7FJKdHASzOV0X0L480jnjd=o=mrG2kZ@mail.gmail.com>
	<AANLkTikyVb3bPXNtvTOq5tQ8iB_SfzCFBb94tqoySPKD@mail.gmail.com>
Date: Wed, 30 Mar 2011 16:29:20 -0700
Message-ID: <AANLkTim4GQP65dGZRrUTNu5jFVTRWyEbGs--eMn9fxoY@mail.gmail.com>
To: Jevon Wright <jevon@jevon.org>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=bcaec50162c5cf15f1049fbb8bed
Subject: Re: [PHP-DEV] Adding a more logical string slicing function to PHP
From: birken@gmail.com (Dan Birken)

--bcaec50162c5cf15f1049fbb8bed
Content-Type: text/plain; charset=ISO-8859-1

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 <jevon@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 <birken@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
>
>

--bcaec50162c5cf15f1049fbb8bed--