Hi,
On Fri, Dec 13, 2013 at 8:00 PM, Kris Craig <kris.craig@gmail.com> wrote:
>
>
>
> On Fri, Dec 13, 2013 at 12:15 AM, Tjerk Meesters <tjerk.meesters@gmail.com
> > wrote:
>
>> Hi,
>>
>> On Fri, Dec 13, 2013 at 3:09 PM, Kris Craig <kris.craig@gmail.com> wrote:
>>
>>> On Thu, Dec 12, 2013 at 9:58 PM, Marc Bennewitz <php@marc-bennewitz.de
>>> >wrote:
>>>
>>> > Hi
>>> >
>>> > Decrementing "a" to a number isn't a good idea because on
>>> > incrementing
>>> > again you will increment the number and not go back to "a".
>>> >
>>>
>>> Why not just have "a" decrement to an empty string (i.e. "") and an
>>> empty
>>> string increment to "a"?
>>
>>
>> Imagine a scenario in which an empty posted value is assumed to be a
>> number and so ++$x is applied; instead of getting the expected "1" they now
>> get "a" which, after an (int) cast will become 0 .. surprise!
>>
>
> Yikes, that's a good point.
>
> Ok, so just to play devil's advocate here, would it be completely awful to
> have (int) "a" == 1, (int) "b" == 2, etc? I'm not advocating this,
> mind
> you. In fact, I hate the idea, but I think it bears mentioning as it would
> resolve the problem you mentioned (while no doubt creating a whole bunch of
> new problems).
>
>
>> Then a decrement on an empty string could trigger
>>> a warning and remain empty. That way, we won't have situations where
>>> decrementing from "a" and incrementing back would output a number.
>>>
>>
>> Actually, the increment of "" is "1", which is still a string; the
>> increment of "1" is int(2), though.
>>
>
> Also a good point. It sounds like applying incremental behavior to
> non-numeric strings using standard arithmetic +/- operators might prove to
> be prohibitively problematic in such a loosely typed language as PHP.
>
>
>>
>> That said, isn't it bad enough that php already has exceptions such as:
>> * ++$x is not always the same as $x += 1
>> * ++false remains false, but ++null becomes int(1)
>>
>
> I agree. I've never liked either behavior.
>
>
>>
>> If decrementing strings should work, I would request to also make ++false
>> => true and --true => false
>>
>
> I'd be for that, actually.
>
>
>>
>> Lastly, if I could go back in time I would have created str_inc() and
>> str_dec() so that + has a unambiguous meaning :)
>>
>
> Honestly, I don't think it's too late to do that now. At very least,
> those functions could be added without modifying the existing +/- behavior.
> Then that behavior could be changed in the next *major* release, since
> some BC behavior changes are to be expected then.
>
As a matter of fact, I've created a rough patch, not to lobby against the
ability to decrement_string() per se, but to move string logic to where it
belongs; inside ext/standard/string.c
The branch differences can be found here:
https://github.com/datibbaw/php-src/compare/master...inc-dec-patch
Basically it makes the $x++ or ++$x work as if you types $x +=
1 or
$x = $x + 1 (except for arrays, currently)
So:
++false becomes int(1), --false becomes int(-1)
++true becomes int(2), --true becomes int(0)
++null becomes int(1), --null becomes int(-1)
++"123a" becomes "123b" but with a notice that string increment is
deprecated
It would introduce the following two string functions, both return a new
value (i.e. pass by value):
* str_inc($str)
* str_dec($str)
E.g.:
for ($x = "a"; $x < "g"; $x = str_inc($x));
This could be a nice change for the next major version, e.g. (5next).0
>
>>
>>
>>>
>>> --Kris
>>>
>>
>>
>>
>> --
>> --
>> Tjerk
>>
>
>
--
--
Tjerk