Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51747
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.170 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=O8m/hpqxRaHhizG2s2b6ecAes3E1+qUzbzUuk1amCssmgIsZm8OSLdRcOSPUeJIlOb
         HpmcCxC1XQit6+Pp+cgZHoIaMyTHQVJBKJHz0BK9wPT2K7/ZTOjtxVAW6YwJwAQXte84
         o+gfEcvGr7w7QBp/tWhzfuu9eFr7t8oSOR7ao=
MIME-Version: 1.0
In-Reply-To: <4D92CC38.5040900@toolpark.com>
References: <AANLkTinWgyueX7FJKdHASzOV0X0L480jnjd=o=mrG2kZ@mail.gmail.com>
	<4D92CC38.5040900@toolpark.com>
Date: Wed, 30 Mar 2011 00:42:20 -0700
Message-ID: <AANLkTimpmjOQcqLcfH23Zrt6EULw6PAJvQ1_cvAP7ON=@mail.gmail.com>
To: Lars Schultz <lars.schultz@toolpark.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=20cf307f3ba61e0a1e049fae513a
Subject: Re: [PHP-DEV] Adding a more logical string slicing function to PHP
From: birken@gmail.com (Dan Birken)

--20cf307f3ba61e0a1e049fae513a
Content-Type: text/plain; charset=ISO-8859-1

I think when the values are positive everything is mostly great.  I think
when the values are negative is where the main problems are.  Both the C
function strncpy() and the C++ strings substr() function only support
positive values for length AFAIK.

I just think it is very unintuitive for the first parameter always to be a
position, and the 2nd parameter to be a length if the value is positive, and
a position if the value is negative.

substr('string', 1, 2); // Goes from position 1 to position 3
substr('string', -2, -1); // Goes from position -2 to position -1

So here is the same kind of thing in python, which uses [start, end):
string[1:2] ==> 't'
string[-2:-1] ==> 'n'

And ruby, which uses [start, end]:
"string"[2..3] ==> 'tr'
"string"[-2:-1] ==> 'ng'

Both of these languages use positions for positive and negative values.  In
addition, in both of these languages if you slice a string impossibly, both
of them return an empy string as opposed to false, which just seems more
intuitive to me.

I don't think this function is particularly novel, I just think both
returning an empty string on impossible slicing and slicing based on
positions are improvements, and combined I think this function is noticeably
more durable and readable than substr().

-Dan

On Tue, Mar 29, 2011 at 11:22 PM, Lars Schultz <lars.schultz@toolpark.com>wrote:

> 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
>>
>>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--20cf307f3ba61e0a1e049fae513a--