Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87256
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.15.19 as permitted sender)
Message-ID: <55B17FE2.5090208@gmx.de>
Date: Fri, 24 Jul 2015 01:59:30 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: francois@php.net, internals@lists.php.net
References: <001201d0c574$e1b63f80$a522be80$@php.net>
In-Reply-To: <001201d0c574$e1b63f80$a522be80$@php.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [Proposal] Extend support for negative string offsets
From: cmbecker69@gmx.de (Christoph Becker)

François Laupretre wrote:

> I need your thoughts on a PR (https://github.com/php/php-src/pull/1431) I am
> working on. The subject is to change the way negative string offsets (and
> lengths, where applicable) are handled, to make the behavior consistent with
> the way they're handled in substr() and substr_replace(). If your return is
> positive, I'll write the corresponding RFC.
> 
> Implemented so far :
> 
> - Support negative string offsets in read mode. Example: $a = $string{-2};
> 
> - Support negative string offsets in assignment mode. Example: $string{-2} =
> 'z';

Generally, I like the idea of being able to specify negative string
offsets.  However, I'm usually working with UTF-8 strings, and as such
I'm using string offsets rather seldom.

> - strpos() : Accept negative values for the '$offset' argument
> 
> - stripos() : Accept negative values for the '$offset' argument
> 
> - substr_count(): Accept negative values for the '$offset' and '$length'
> parameters (same behavior as in substr()).

That may be useful as well, but what about the respective mbstring and
grapheme functions?  At least these should be improved as well, but I'm
not sure if that can be done in an efficient manner.

> I also have some questions :
> 
> - Should we keep returning NULL on parameter parsing failure, while
> documentation only states that false is returned on failure ?

It is documented[1] that:

| If the parameters given to a function are not what it expects, such
| as passing an array where a string is expected, the return value of
| the function is undefined. In this case it will likely return NULL
| but this is just a convention, and cannot be relied upon.

IMHO it's best to stick with the current behavior, and to consider to
raise exceptions sometime in the future.

[1] <http://php.net/manual/en/functions.internal.php>

-- 
Christoph M. Becker