Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51746
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain toolpark.com from 195.49.42.12 cause and error)
Message-ID: <4D92CC38.5040900@toolpark.com>
Date: Wed, 30 Mar 2011 08:22:48 +0200
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4
MIME-Version: 1.0
To: internals@lists.php.net
References: <AANLkTinWgyueX7FJKdHASzOV0X0L480jnjd=o=mrG2kZ@mail.gmail.com>
In-Reply-To: <AANLkTinWgyueX7FJKdHASzOV0X0L480jnjd=o=mrG2kZ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Adding a more logical string slicing function to PHP
From: lars.schultz@toolpark.com (Lars Schultz)

I just love substr() and I think all other languages got it wrong;)

Seriously...it behaves the same as implementations in other languages as 
long as values are positive, right? how is that counter-intuitive? How 
do other languages handle negative values?

Am 30.03.2011 08:06, schrieb Dan Birken:
> 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
>