Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [VOTE] [RFC] Alphanumeric Decrement »

[VOTE] [RFC] Alphanumeric Decrement

php.internals

Andrew Faulds

12 years ago
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/

Stas Malyshev

12 years ago
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
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

Andrew Faulds

12 years ago
On 21/01/14 00:37, Stas Malyshev wrote:
> I'd recommend moving the RFC to "voting" part of the wiki when > announcing a vote.
Good catch! Done.
-- Andrea Faulds http://ajf.me/

Yasuo Ohgaki

12 years ago
Hi Andrea, On Tue, Jan 21, 2014 at 9:10 AM, Andrea Faulds <ajf@ajf.me> wrote:
> 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 >
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

Andrew Faulds

12 years ago
On 21/01/14 19:12, Yasuo Ohgaki wrote:
> 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/

Lars Strojny

12 years ago
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 On 21 Jan 2014, at 21:16, Andrea Faulds <ajf@ajf.me> wrote:

Chris Wright

12 years ago
On 21 January 2014 20:47, Lars Strojny <lars@strojny.net> wrote:
> 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 :)
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

Yasuo Ohgaki

12 years ago
Hi Andrea, On Wed, Jan 22, 2014 at 5:16 AM, Andrea Faulds <ajf@ajf.me> wrote:
> 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

Sanford Whiteman

12 years ago
> Added this RFC to keep track inconsistency.
> https://wiki.php.net/rfc/comparison_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.

Andrew Faulds

12 years ago
On 21/01/14 00:10, Andrea Faulds wrote:
> 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/

Yasuo Ohgaki

12 years ago
Hi Andrea, On Tue, Jan 28, 2014 at 9:44 AM, Andrea Faulds <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. 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

Andrew Faulds

12 years ago
On 28/01/14 01:15, Yasuo Ohgaki wrote:
> 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/

Tjerk Meesters

12 years ago
Hi Andrea, On Tue, Jan 28, 2014 at 9:34 AM, Andrea Faulds <ajf@ajf.me> wrote:
> > > On 28/01/14 01:15, Yasuo Ohgaki wrote: > >> 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/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- -- Tjerk

Yasuo Ohgaki

12 years ago
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? > > https://wiki.php.net/rfc/normalize_inc_dec >
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

Tjerk Meesters

12 years ago
Hi, On Tue, Jan 28, 2014 at 10:51 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> 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? >> >> https://wiki.php.net/rfc/normalize_inc_dec >> > > 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

Rouven Weßling

12 years ago
> On 28.01.2014, at 07:12, Tjerk Meesters <tjerk.meesters@gmail.com> wrote: > > 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

Robert Stoll

12 years ago
> -----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 Decrement > > > > On 28.01.2014, at 07:12, Tjerk Meesters <tjerk.meesters@gmail.com> wrote: > > > > 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. >
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