Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51755
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=bffVYN/RIqGQzEXBsmfMh0axe0OVJFd+uFI3PJeSIKkQH8VvmQMt8HkDp795psX2BG
         b6YFX7staF+d4UiWIHgM0ydZVxMy/lDx3H7TxBA5daNTrWxqytliEZqR51WG5g70Hzxu
         dhTFoC89EBSb2vzpXz6etraf3cM2zBOOoosw8=
MIME-Version: 1.0
In-Reply-To: <004301cbeee8$e54a8280$afdf8780$@com>
References: <AANLkTinWgyueX7FJKdHASzOV0X0L480jnjd=o=mrG2kZ@mail.gmail.com>
	<4D92CC38.5040900@toolpark.com>
	<AANLkTimpmjOQcqLcfH23Zrt6EULw6PAJvQ1_cvAP7ON=@mail.gmail.com>
	<AANLkTinp1wnOu6te6MjoONcz_1AVobc7pwFwvbY8mkTB@mail.gmail.com>
	<004301cbeee8$e54a8280$afdf8780$@com>
Date: Wed, 30 Mar 2011 12:36:55 -0700
Message-ID: <AANLkTi=MTU=AM-FeX1ZbTrrEDdNCPWNvcppWrxxbWGcg@mail.gmail.com>
To: Jonathan Bond-Caron <jbondc@openmv.com>
Cc: Hannes Landeholm <landeholm@gmail.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=bcaec5186a4ca070c3049fb84c54
Subject: Re: [PHP-DEV] Adding a more logical string slicing function to PHP
From: birken@gmail.com (Dan Birken)

--bcaec5186a4ca070c3049fb84c54
Content-Type: text/plain; charset=ISO-8859-1

The example I picked in my patch was a little contrived, however I do think
it is a useful benefit for functions to work in ways people expect, even in
edge cases.  There are a lot of people out there who do not know the
difference between == and ===, and I think the fact that str_slice() has one
less potential bug to worry about is a tangible improvement.

As for adding other string functions, I agree, I think there are a lot of
them that would be great to add.  starts_with & ends_with for sure.  I just
didn't want to write a really large patch for a whole host of functions
before having the discussion about this one.

I also don't mean to attack PHP.  I think the interface for this function is
heavily borrowed from C, and I think because PHP has different goals than C
(ease of use being one of them), that improvements can be made from this
perspective.  I think from a functionality point of view for an expert user,
the C function interfaces are great.

-Dan

On Wed, Mar 30, 2011 at 7:43 AM, Jonathan Bond-Caron <jbondc@openmv.com>wrote:

> On Wed Mar 30 09:05 AM, Hannes Landeholm wrote:
> >
> > var_dump(\substr("foo", 5, 6) == "", (string) false, false == "");
> >
> > Welcome to PHP. To be honest this criticism pretty much falls in the
> > "from person that comes from another language X and is annoyed that
> > every little detail isn't exactly the same"-category. Just make your
> > own substr() function that uses the behavior you expect if you don't
> > like the native version. Although that's bad practice - the best
> > solution is to get used to it. And if you have an urge to write about
> > your experience with a new language I suggest you do it in a blog
> > instead of posting it in the internals mailing list...
>
> I agree with what you're saying but I think you're being a little harsh,
> experience with a new language should be something that matters to
> internals.
>
> Back to Dan, you're hitting type conversion so not sure I understand "you
> always have to deal with this FALSE case":
>
> var_dump(substr('', -1) == '0'); // TRUE
> var_dump(substr('', -1) === '0'); // FALSE
>
> Equally to Dan, it doesn't seem like a great way to start the conversation
> by saying the "interface is inconsistent and confusing".
> There's a perception issue here since you're already used to using language
> X,Y,Z.
>
> That said the patch seems to add value to php, why not add str_slice() if
> it
> can solve consistency issues for some users? str_slice likely could be a
> faster alternative to substr() in userland parsers.
>
> Also I've seen plenty of bugs caused by type conversion & substr() in
> userland
>
>
>

--bcaec5186a4ca070c3049fb84c54--