Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71403
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.171 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <F23DFA7B-D1B1-4AB8-8DB8-4D4D8406934B@strojny.net>
References: <52DDBAE5.2010803@ajf.me>
	<CAGa2bXYG_x-t98HborB1sVB6wBdFE7OMeDz1NoFW7_zzMVciag@mail.gmail.com>
	<52DED5B5.9050905@ajf.me>
	<F23DFA7B-D1B1-4AB8-8DB8-4D4D8406934B@strojny.net>
Date: Wed, 22 Jan 2014 10:38:50 +0000
Message-ID: <CAGAGxbaTfMt0zYbriAW2c5rTXrNe2mosuJ_Sw5q3brxrTCvizw@mail.gmail.com>
To: Lars Strojny <lars@strojny.net>
Cc: Andrea Faulds <ajf@ajf.me>, Yasuo Ohgaki <yohgaki@ohgaki.net>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] [RFC] Alphanumeric Decrement
From: daverandom@php.net (Chris Wright)

On 21 January 2014 20:47, Lars Strojny <lars@strojny.net> wrote:
> I would rather introduce a deprecation warning for decrementing (and
> incrementing) alphanumeric strings. It=92s just very bad behaviour and us=
ing
> chr() and ord() is not that hard :)

Agreed that the *current* behaviour is very bad and not hugely useful.
Being able to increment and decrement "strings" is, however, often
useful behaviour when dealing with binary data, and chr()/ord() can be
expensive in this scenario.

I would like to have something closer to C's behaviour, where (given
that in PHP a string is essentially just a char*) I can access a
character in a string by index (returns a string) and manipulate it
arithmetically - so inc/dec would alter the byte value by 1, over the
full range 0-255. If this were the case, I would expect an inc/dec
operation on a string >1 character to apply the operation to the first
character in the string, and operating on an empty string would
produce an E_NOTICE.

I would hate to see a deprecation warning issued now if it's possible
the behaviour could be made more sensible in the future and
"undeprecated".

Obviously this kind of BC-break would be for a new major version, I'm
not suggesting this is done immediately.

For the record, this also sums up why I have voted "no" on the current
RFC - I don't want to introduce more counter-intuitive behaviour when
there is a much more intuitive (and useful) alternative.

Thanks, Chris