Hi,
I've decided I might as well open a vote on this RFC, lest it be
otherwise abandoned.
Voting starts today (2014-01-21), ends 2014-01-28.
https://wiki.php.net/rfc/alpanumeric_decrement
Thanks.
--
Andrea Faulds
http://ajf.me/
Hi!
I've decided I might as well open a vote on this RFC, lest it be
otherwise abandoned.Voting starts today (2014-01-21), ends 2014-01-28.
I'd recommend moving the RFC to "voting" part of the wiki when
announcing a vote.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
I'd recommend moving the RFC to "voting" part of the wiki when
announcing a vote.
Good catch! Done.
--
Andrea Faulds
http://ajf.me/
Hi Andrea,
I've decided I might as well open a vote on this RFC, lest it be otherwise
abandoned.Voting starts today (2014-01-21), ends 2014-01-28.
Added this RFC to keep track inconsistency.
https://wiki.php.net/rfc/comparison_inconsistency
Python/Ruby does not even have ++/--.
Mixing string and number raises type error for these languages.
Perl returns -1 for string-- always.
Although behavior became more consistent than now, but
I'm not sure if this change is good or not.
Keeping current behavior might be better.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Added this RFC to keep track inconsistency.
https://wiki.php.net/rfc/comparison_inconsistency
Python/Ruby does not even have ++/--.
Mixing string and number raises type error for these languages.
Perl returns -1 for string-- always.Although behavior became more consistent than now, but
I'm not sure if this change is good or not.
Keeping current behavior might be better.
This would also be my preferred approach. My RFC is one approach to
resolving the inconsistency, but it's not what I really want, in truth.
I'd like something like that you're proposing.
However I think type juggling is entirely misguided, and should we do it
at all, int -> string and float -> string should be one-way conversions.
Doing the reverse seems like a bad idea to me.
--
Andrea Faulds
http://ajf.me/
I would rather introduce a deprecation warning for decrementing (and incrementing) alphanumeric strings. It’s just very bad behaviour and using chr() and ord() is not that hard :)
cu,
Lars
Added this RFC to keep track inconsistency.
https://wiki.php.net/rfc/comparison_inconsistency
Python/Ruby does not even have ++/--.
Mixing string and number raises type error for these languages.
Perl returns -1 for string-- always.Although behavior became more consistent than now, but
I'm not sure if this change is good or not.
Keeping current behavior might be better.This would also be my preferred approach. My RFC is one approach to resolving the inconsistency, but it's not what I really want, in truth. I'd like something like that you're proposing.
However I think type juggling is entirely misguided, and should we do it at all, int -> string and float -> string should be one-way conversions. Doing the reverse seems like a bad idea to me.
--
Andrea Faulds
http://ajf.me/
I would rather introduce a deprecation warning for decrementing (and
incrementing) alphanumeric strings. It’s just very bad behaviour and using
chr()andord()is not that hard :)
Agreed that the current behaviour is very bad and not hugely useful.
Being able to increment and decrement "strings" is, however, often
useful behaviour when dealing with binary data, and chr()/ord() can be
expensive in this scenario.
I would like to have something closer to C's behaviour, where (given
that in PHP a string is essentially just a char*) I can access a
character in a string by index (returns a string) and manipulate it
arithmetically - so inc/dec would alter the byte value by 1, over the
full range 0-255. If this were the case, I would expect an inc/dec
operation on a string >1 character to apply the operation to the first
character in the string, and operating on an empty string would
produce an E_NOTICE.
I would hate to see a deprecation warning issued now if it's possible
the behaviour could be made more sensible in the future and
"undeprecated".
Obviously this kind of BC-break would be for a new major version, I'm
not suggesting this is done immediately.
For the record, this also sums up why I have voted "no" on the current
RFC - I don't want to introduce more counter-intuitive behaviour when
there is a much more intuitive (and useful) alternative.
Thanks, Chris
Hi Andrea,
However I think type juggling is entirely misguided, and should we do it
at all, int -> string and float -> string should be one-way conversions.
Doing the reverse seems like a bad idea to me.
Type safety is good for developing apps with less bugs.
Modern scripting languages have stricter types. One way conversion would be
good for PHP 6 or 5.7 probably. We don't have to restrict it, but raising
E_STRICT without explicit cast would be enough. There may be INI for this
behavior.
I would vote yes if there is such RFC.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Added this RFC to keep track inconsistency.
Don't know what the criteria are for being included on that page, but
https://wiki.php.net/rfc/comparison_inconsistency#string_integer_conversion
is (per your own note on the bug) not a bug at all, fully documented
already in the main docs, and we all know it's never going to change.
So I don't get the utility of calling it inconsistent... is there an
some "inverse" situation with surprising results?
I remember we were discussing this way, way back and I noted that
loose comparison in SQL has the same output (as always, I'm not saying
PHP "is" SQL -- it just seems «de rigueur» to bring other languages
into the discussion these days).
-- S.
Hi,
I've decided I might as well open a vote on this RFC, lest it be
otherwise abandoned.Voting starts today (2014-01-21), ends 2014-01-28.
https://wiki.php.net/rfc/alpanumeric_decrement
Thanks.
Good evening/morning,
We have, to my delight, unanimously rejected this RFC 21 to 0 (∞).
I may now consider proposing an RFC to remove alphanumeric decrement
from PHP 6, instead, considering I also have a patch for that.
Thanks.
Andrea Faulds
http://ajf.me/
Hi Andrea,
We have, to my delight, unanimously rejected this RFC 21 to 0 (∞).
I may now consider proposing an RFC to remove alphanumeric decrement from
PHP 6, instead, considering I also have a patch for that.
As someone mentioned, string decrements can be harder.
I'm not sure if this is good.
Instead, it may be nice to have RFC that raises error for problematic
automatic
casting(type juggling) without explicit cast. Perhaps, INI setting like
strict_cast = ERROR_LEVEL (Default: 0)
It needs additional check that may slow down execution a bit, though.
With this approach, we may have weak type and better type safety.
PHP behaves more like modern scripting languages that have stronger
type safety. Just an idea.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Andrea,
On Tue, Jan 28, 2014 at 9:44 AM, Andrea Faulds <ajf@ajf.me
mailto:ajf@ajf.me> wrote:We have, to my delight, unanimously rejected this RFC 21 to 0 (∞). I may now consider proposing an RFC to remove alphanumeric decrement from PHP 6, instead, considering I also have a patch for that.As someone mentioned, string decrements can be harder.
I'm not sure if this is good.
I'm not exactly sure what you mean. I'd made a mistake, what I meant to
say was "an RFC to remove alphanumeric increment" - decrement is not
currently supported.
--
Andrea Faulds
http://ajf.me/
Hi Andrea,
Hi Andrea,
On Tue, Jan 28, 2014 at 9:44 AM, Andrea Faulds <ajf@ajf.me
mailto:ajf@ajf.me> wrote:We have, to my delight, unanimously rejected this RFC 21 to 0 (∞). I may now consider proposing an RFC to remove alphanumeric decrement from PHP 6, instead, considering I also have a patch for that.As someone mentioned, string decrements can be harder.
I'm not sure if this is good.I'm not exactly sure what you mean. I'd made a mistake, what I meant to
say was "an RFC to remove alphanumeric increment" - decrement is not
currently supported.
I still have an RFC lying around that suggests this, together with some
other changes to how increment / decrement works. Perhaps we could flesh
this out further?
https://wiki.php.net/rfc/normalize_inc_dec
--
Andrea Faulds
http://ajf.me/--
--
Tjerk
Hi Tjerk,
On Tue, Jan 28, 2014 at 10:39 AM, Tjerk Meesters
tjerk.meesters@gmail.comwrote:
I still have an RFC lying around that suggests this, together with some
other changes to how increment / decrement works. Perhaps we could flesh
this out further?
The following behaviour is proposed:
// booleans
$a = false; ++$a; // bool(true)
$a = true; --$a; // bool(false)
// null values
$a = null; --$a; // null
$a = null; ++$a; // null
// empty strings
$a = ''; ++$a; // int(1)
// non-numeric strings
$a = '12d9';
++$a; // string(4) "12e0" + Notice: String increment is deprecated, use
str_inc() instead in php shell code on line 1
++$a; // float(13)
+1 especially boolean++/--.
It's great for flip flop. I guess most users use int++ and int%2 for flip
flop currently.
Existing scripts using ++/-- against bool would be a bug most likely.
Other proposal sounds reasonable to me, too.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi,
Hi Tjerk,
On Tue, Jan 28, 2014 at 10:39 AM, Tjerk Meesters <tjerk.meesters@gmail.com
wrote:
I still have an RFC lying around that suggests this, together with some
other changes to how increment / decrement works. Perhaps we could flesh
this out further?The following behaviour is proposed:
// booleans
$a = false; ++$a; // bool(true)
$a = true; --$a; // bool(false)// null values
$a = null; --$a; // null
$a = null; ++$a; // null// empty strings
$a = ''; ++$a; // int(1)// non-numeric strings
$a = '12d9';
++$a; // string(4) "12e0" + Notice: String increment is deprecated, use
str_inc() instead in php shell code on line 1
++$a; // float(13)+1 especially boolean++/--.
It's great for flip flop. I guess most users use int++ and int%2 for flip
flop currently.
Existing scripts using ++/-- against bool would be a bug most likely.
The RFC doesn't mention this, but the intended behaviour is that $a = true; ++$a; yields bool(true), i.e. no overflow ... however, I'm open to
the suggestion to make it "overflowable", like integer values.
Btw, doing flip/flop can be done with $val = (bool)1 - $val; as well :)
Other proposal sounds reasonable to me, too.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
--
Tjerk
Btw, doing flip/flop can be done with
$val = (bool)1 - $val;as well :)
There's an even easier way:
$val = !$val;
Personally I don't see a need to support increment/decrement for booleans. If at all they should be treated like they were cast to an int first.
Best regards
Rouven
-----Original Message-----
From: Rouven Weßling [mailto:me@rouvenwessling.de]
Sent: Tuesday, January 28, 2014 10:20 AM
To: Tjerk Meesters
Cc: Yasuo Ohgaki; Andrea Faulds; PHP internals
Subject: Re: [PHP-DEV] Re: [VOTE] [RFC] Alphanumeric DecrementBtw, doing flip/flop can be done with
$val = (bool)1 - $val;as well :)There's an even easier way:
$val = !$val;
Personally I don't see a need to support increment/decrement for booleans. If at all they should be treated like they
were
cast to an int first.
In my opinion, it really should behave like an int for ++/--
Yet, I would not mind if ++false = true and beginning with true it would change to int -> ++true = 2, --true=false,
--false = -1 respectively