Re: [PROPOSAL] Alphanumeric decrement

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 >