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.
>
>
>>
>> --Kris
>>
>
>
>
> --
> --
> Tjerk
>