Good evening,
At present, it's possible to increment (++) an alphanumeric string, such
that "a" when incremented becomes "b", "z" becomes "aa", and so on.
However, it's irritated me that the same is not true for the decrement
(--) operator. At present, "aa" when decremented stays as "aa", and "b"
when decremented stays as "b". This lack of symettry is counterintuitive
to me. I don't think it's what you would expect here.
So I've written a patch which would change this. "aa" when decremented
would be "z", and "b" when decremented would be "a". It also handles
decrementing "a", which becomes "0". This creates an interesting new
asymettry: {$a = "a"; $a--; $a++;} will result in $a being integer 1. I
think it's better than the previous behaviour, though, which resulted in
"b".
The diff is here:
https://github.com/TazeTSchnitzel/php-src/compare/php:PHP-5.6...AlphanumericDecrement
My aim is to try and get this into PHP 5.6, if people are interested.
Thoughts?
--
Andrea Faulds
http://ajf.me/
So I've written a patch which would change this. "aa" when decremented would
be "z", and "b" when decremented would be "a". It also handles decrementing
"a", which becomes "0". This creates an interesting new asymettry: {$a =
"a"; $a--; $a++;} will result in $a being integer 1. I think it's better
than the previous behaviour, though, which resulted in "b".
I wonder if we'd want to warn when 'a' decrements to 0, since it's a
somewhat unintuitive behaviour. (Also, since Perl will decrement 'a'
to -1 and Perl was the original inspiration, do we want to decrement
to -1 as well for consistency?)
The diff is here:
https://github.com/TazeTSchnitzel/php-src/compare/php:PHP-5.6...AlphanumericDecrementMy aim is to try and get this into PHP 5.6, if people are interested.
Thoughts?
I haven't looked closely at the diff yet, but +1 on the idea. We've
always documented that decrement doesn't work, so there shouldn't be a
BC concern there.
Adam
I wonder if we'd want to warn when 'a' decrements to 0, since it's a
somewhat unintuitive behaviour. (Also, since Perl will decrement 'a'
to -1 and Perl was the original inspiration, do we want to decrement
to -1 as well for consistency?)
Ooh, I didn't know about Perl's -1 behaviour. That might be a better
idea, since "z" becoming "aa" suggests that "a" is functions more like 0
here than 1. That, or the warning you suggest.
Also, I forgot to mention in my original post, but there is another
thing changed by this patch. At present, when decrementing a string, it
is treated as an integer zero if it is empty. This patch also removes
that check. This brings incrementing into line with decrementing. ""
would increment to "1" and decrement to "-1", while at present it
decrements to -1 (the integer).
Andrea Faulds
http://ajf.me/
This topic has been discussed before, see http://marc.info/?l=php-internals&m=137415522724276&w=1 for the thread
I wonder if we'd want to warn when 'a' decrements to 0, since it's a
somewhat unintuitive behaviour. (Also, since Perl will decrement 'a'
to -1 and Perl was the original inspiration, do we want to decrement
to -1 as well for consistency?)Ooh, I didn't know about Perl's -1 behaviour. That might be a better idea, since "z" becoming "aa" suggests that "a" is functions more like 0 here than 1. That, or the warning you suggest.
Also, I forgot to mention in my original post, but there is another thing changed by this patch. At present, when decrementing a string, it is treated as an integer zero if it is empty. This patch also removes that check. This brings incrementing into line with decrementing. "" would increment to "1" and decrement to "-1", while at present it decrements to -1 (the integer).
Andrea Faulds
http://ajf.me/
This topic has been discussed before, see
http://marc.info/?l=php-internals&m=137415522724276&w=1 for the thread
Thanks for that. Silly of me not to have had a look at previous
discussions - I knew I'd forgotten something!
Looks like not much happened in that thread, and it wasn't agreed
particularly that it should or shouldn't be done. This thread might be
different as there's a patch.
By the way, this implementation would make "XYZ0000" decrement to
"XYY9999" as Peter Lind had suggested there, since the string decrement
implementation was deliberately made to be a direct inverse of the
string increment implementation.
--
Andrea Faulds
http://ajf.me/
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".
In my opinion this should be a warning/error and the value should stay
as "a".
This warning/error should be triggered on incrementing/decrementing a
non alphanumeric string (inclusive an empty string), too.
Greetings
Marc
Am 12.12.2013 21:02, schrieb Andrea Faulds:
Good evening,
At present, it's possible to increment (++) an alphanumeric string, such
that "a" when incremented becomes "b", "z" becomes "aa", and so on.However, it's irritated me that the same is not true for the decrement
(--) operator. At present, "aa" when decremented stays as "aa", and "b"
when decremented stays as "b". This lack of symettry is counterintuitive
to me. I don't think it's what you would expect here.So I've written a patch which would change this. "aa" when decremented
would be "z", and "b" when decremented would be "a". It also handles
decrementing "a", which becomes "0". This creates an interesting new
asymettry: {$a = "a"; $a--; $a++;} will result in $a being integer 1. I
think it's better than the previous behaviour, though, which resulted in
"b".The diff is here:
https://github.com/TazeTSchnitzel/php-src/compare/php:PHP-5.6...AlphanumericDecrementMy aim is to try and get this into PHP 5.6, if people are interested.
Thoughts?
On Thu, Dec 12, 2013 at 9:58 PM, Marc Bennewitz php@marc-bennewitz.dewrote:
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"? 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.
--Kris
Hi,
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!
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.
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)
If decrementing strings should work, I would request to also make ++false
=> true and --true => false
Lastly, if I could go back in time I would have created str_inc() and
str_dec() so that + has a unambiguous meaning :)
--Kris
--
Tjerk
On Fri, Dec 13, 2013 at 12:15 AM, Tjerk Meesters
tjerk.meesters@gmail.comwrote:
Hi,
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
Hi,
On Fri, Dec 13, 2013 at 12:15 AM, Tjerk Meesters <tjerk.meesters@gmail.com
wrote:
Hi,
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 => falseI'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
-----Original Message-----
From: Tjerk Meesters [mailto:tjerk.meesters@gmail.com]
Sent: Friday, December 13, 2013 1:54 PM
To: Kris Craig
Cc: Marc Bennewitz; PHP internals list
Subject: Re: [PHP-DEV] [PROPOSAL] Alphanumeric decrementThat 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)
[Robert Stoll]
Thanks for this information, I wasn't even aware of that PHP behaves so strange when it comes to true/false in
combination with the ++ or -- operator.
I always expected that they would behave like int's when an arithmetic operator is applied.
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.cThe branch differences can be found here:
https://github.com/datibbaw/php-src/compare/master...inc-dec-patchBasically it makes the
$x++or++$xwork as if you types$x += 1or
$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
[Robert Stoll]
+1
Awesome, that's exactly what I would expect (except the last line but I never do such things anyway)
Tjerk Meesters wrote (on 13/12/2013):
Basically it makes the
$x++or++$xwork as if you types$x += 1or
$x = $x + 1(except for arrays, currently)
++null becomes int(1), --null becomes int(-1)
Yes please! One of my colleagues once raised a bug that currently
incrementing null results in 1, but decrementing it results in it
remaining null. On the other hand, null -= 1 results in -1 as you
would expect.
The bug was closed as invalid, stating that this is documented
behaviour, but I have never understood why this would be anything other
than an accidental side effect of implementation, nor why you would ever
rely on it.
++"123a" becomes "123b" but with a notice that string increment is
deprecated
Lukewarm on this part; the current syntax seems fairly logical to me,
and the proposed new functions more ugly for no very good reason.
Regards,
Rowan Collins
[IMSoP]
On Tue, Dec 17, 2013 at 2:26 AM, Rowan Collins rowan.collins@gmail.comwrote:
Tjerk Meesters wrote (on 13/12/2013):
Basically it makes the
$x++or++$xwork as if you types$x += 1or
$x = $x + 1(except for arrays, currently)
++null becomes int(1), --null becomes int(-1)Yes please! One of my colleagues once raised a bug that currently
incrementing null results in 1, but decrementing it results in it remaining
null. On the other hand,null -= 1results in -1 as you would expect.The bug was closed as invalid, stating that this is documented behaviour,
but I have never understood why this would be anything other than an
accidental side effect of implementation, nor why you would ever rely on it.++"123a" becomes "123b" but with a notice that string increment is
deprecated
Lukewarm on this part; the current syntax seems fairly logical to me, and
the proposed new functions more ugly for no very good reason.
I would love to completely eradicate it, but I also realize that there's
existing code using it, such as:
for ($class = 'A1'; $class <= 'A4'; ++$class);
It might be hard to find the places where such code is being used, so I
figured it made sense to have a deprecation period instead.
Regards,
Rowan Collins
[IMSoP]--
--
Tjerk
I would love to completely eradicate it, but I also realize that there's
existing code using it, such as:for ($class = 'A1'; $class <= 'A4'; ++$class);
It might be hard to find the places where such code is being used, so I
figured it made sense to have a deprecation period instead.
Before writing the -- support patch, I wrote a patch to remove ++
support. There were a few tests that relied on the feature which
required rewriting, so I'm quite worried about what'd happen if we
removed it. Maybe in 6.0?
--
Andrea Faulds
http://ajf.me/
I would love to completely eradicate it, but I also realize that there's
existing code using it, such as:Before writing the -- support patch, I wrote a patch to remove ++
support. There were a few tests that relied on the feature which
required rewriting, so I'm quite worried about what'd happen if we
removed it. Maybe in 6.0?
Genuine question: what is the actual case for removing the current
operator in favour of a function? Is it to make a clearer separation
between string and numeric operations? Or that it feels like a function
should have been created rather than overloading the operator in the
first place?
Regardless of deprecation period, this is one of those things that is
quite hard to track down - you can't just grep your codebase for
instances like you can with a function being removed.
Regards,
--
Rowan Collins
[IMSoP]
On Tue, Dec 17, 2013 at 8:11 AM, Rowan Collins rowan.collins@gmail.comwrote:
I would love to completely eradicate it, but I also realize that there's
existing code using it, such as:Before writing the -- support patch, I wrote a patch to remove ++
support. There were a few tests that relied on the feature which required
rewriting, so I'm quite worried about what'd happen if we removed it. Maybe
in 6.0?Genuine question: what is the actual case for removing the current
operator in favour of a function? Is it to make a clearer separation
between string and numeric operations? Or that it feels like a function
should have been created rather than overloading the operator in the first
place?
For the sake of clarity I should reiterate the purpose of my patch; it's to
disambiguate the behaviour of ++ across the different data types by
treating the operands as numbers; this also means deprecating the current
++ behaviour on strings and instead moving the functionality under "string
functions".
So to answer your question, a bit of both but - personally - more of the
latter.
Regardless of deprecation period, this is one of those things that is
quite hard to track down - you can't just grep your codebase for instances
like you can with a function being removed.
Indeed, it has the potential of dragging on like the deprecation of
register_globals or magic_quotes did. Given the current state of error
logging, this probably remains the biggest risk.
Regards,
--
Rowan Collins
[IMSoP]--
--
Tjerk
Hi Andrea,
At present, it's possible to increment (++) an alphanumeric string, such
that "a" when incremented becomes "b", "z" becomes "aa", and so on.However, it's irritated me that the same is not true for the decrement
(--) operator. At present, "aa" when decremented stays as "aa", and "b"
when decremented stays as "b". This lack of symettry is counterintuitive to
me. I don't think it's what you would expect here.So I've written a patch which would change this. "aa" when decremented
would be "z", and "b" when decremented would be "a". It also handles
decrementing "a", which becomes "0". This creates an interesting new
asymettry: {$a = "a"; $a--; $a++;} will result in $a being integer 1. I
think it's better than the previous behaviour, though, which resulted in
"b".The diff is here: https://github.com/TazeTSchnitzel/php-src/
compare/php:PHP-5.6...AlphanumericDecrementMy aim is to try and get this into PHP 5.6, if people are interested.
Thoughts?
Your proposal would be more intuitive than the current behavior
in most cases.
While a go, I was about to propose similar patch, but I didn't.
I think the reason was that I've concluded it is impossible to
make string decrements logical anyway.
Just my .02c
I'll read your patch and may comment if there is something to say.
There are users who use string increment now, but I suppose nobody
is using string decrements because it's not working as most people
expect. Edge case should be considered carefully, since it would
cause more confusion than now.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Good evening,
At present, it's possible to increment (++) an alphanumeric string, such
that "a" when incremented becomes "b", "z" becomes "aa", and so on.However, it's irritated me that the same is not true for the decrement
(--) operator. At present, "aa" when decremented stays as "aa", and "b"
when decremented stays as "b". This lack of symettry is counterintuitive to
me. I don't think it's what you would expect here.So I've written a patch which would change this. "aa" when decremented
would be "z", and "b" when decremented would be "a". It also handles
decrementing "a", which becomes "0". This creates an interesting new
asymettry: {$a = "a"; $a--; $a++;} will result in $a being integer 1. I
think it's better than the previous behaviour, though, which resulted in
"b".The diff is here: https://github.com/TazeTSchnitzel/php-src/
compare/php:PHP-5.6...AlphanumericDecrementMy aim is to try and get this into PHP 5.6, if people are interested.
Thoughts?--
Andrea Faulds
http://ajf.me/--
Hi,
While I agree that the current implementation is unintuitive, I would be
against changing it in a minor version.
In this thread multiple people mentioned that it would be ok to change the
alpha decrementing, because it wasn't working before and/or nobody would
use it as it isn't working currently.
I think you misuse the "not working" here. It works (as it doesn't throw an
error), but it behaves differently, what you would like/expect to see, and
we also have this behavior documented.
So changing the behavior in my opinion would be a BC break, and given the
nature of this feature, I think that there are no solution, which would
eliminate all the edge-cases and make the feature truly consistant/symetric
to the current incrementing and to our type juggling, so I think we can't
even call it a bugfix(and ship it in a minor), when we change it from
mostly-broken to slightly-broken.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
So changing the behavior in my opinion would be a BC break, and given
the nature of this feature, I think that there are no solution, which
would eliminate all the edge-cases and make the feature truly
consistant/symetric to the current incrementing and to our type
juggling, so I think we can't even call it a bugfix(and ship it in a
minor), when we change it from mostly-broken to slightly-broken.
It is technically a BC-break if something relies on being able to
infinitely decrement alphanumerics and have the same result, but I doubt
any code actually relies on it.
I think this entirely consistent with incrementing at present, with the
one exception of "a" decrementing to zero. Making "a" not decrement at
all is a compromise I might consider.
At risk of derailing the thread, I think the current "no BC breaks in
minors" policy is somewhat misguided. The problem is that a lot of
bugfix are technically a BC break (unless code is supposed to be
consistent with how PHP's supposed to work and not how it actually
works), and in practise you'll have to introduce some BC breaks when
adding new features (for example, making certain constant names keywords
would break existing code which used those names). Hence perhaps we
should change the rules to say that certain BC breaks are allowed, but
only in very limited and specific circumstances.
--
Andrea Faulds
http://ajf.me/
My aim is to try and get this into PHP 5.6, if people are interested.
Thoughts?
I've created an RFC: https://wiki.php.net/rfc/alpanumeric_decrement
--
Andrea Faulds
http://ajf.me/