Re: [PROPOSAL] Alphanumeric decrement

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