Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On Tue, 17 Jan 2023 at 14:28, G. P. B. wrote: > Hello Internals, > > I would like to start the discussion on the Path to Saner > Increment/Decrement operators RFC: > https://wiki.php.net/rfc/saner-inc-dec-operators > > The goal of this RFC is to reduce language complexity by making $v++ > behave like $v += 1 and $v-- behave like $v -= 1; > > I am expecting the contentious part of the proposal to be the deprecation > of the PERL string increment feature to achieve the aforementioned goal. > However, I believe the benefits of aligning the behaviour of the > increment/decrement operators with addition/subtraction are larger than > keeping support for the PERL increment, which in its current state has > various shortcomings. > I have added a section about impact on the PERL increment deprecation to the RFC. https://wiki.php.net/rfc/saner-inc-dec-operators I am also planning on opening the vote on this on Wednesday the 28th of June. Best regards, George P. Banyard
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
Hey All On 01.02.23 07:20, Mark Baker wrote: On 23/01/2023 14:06, G. P. B. wrote: However, the whole point of this RFC is to*remove* cognitive burden for developers, so they don't even need to be aware of this "feature" and not get surprised when it kicks in. Moreover, by your logic, you wouldn't care if we removed support for alphanumeric strings and only let the PERL increment kick in for purely alphabetical. While convenient for you, someone might actually use this feature on alphanumeric strings, and we're back to "why is my use case being removed while that other just as weird one remains". I make no judgement on alphanumeric strings, other than I can't see any use case for it myself, so I won't allow my objection be considered hypocritical; and your definition of my use case as "weird" is highly judgemental. Bijective numeration using the letters of the alphabet has a long and ancient tradition, pre-dating our modern numeric Hindu-Arabic system using base 10 for place/value notation by many centuries. The Abjadi system used the 28 letters of the Arabic alphabet; similarly the ancient Greeks and Hebrews, the Armenians; by Russia until the early 18th Century (each culture using their own alphabet). It's ironic that the Romans used a very different system, even though our modern western alphabet is based on the Roman alphabet. These civilisations didn't consider their alphabetic numeral system "weird". How many of the irregularities and idiosyncracies of alphanumeric strings could be resolved by not trying to cast them as a numeric value before increment/decrement; but by treating them consistently as strings? It would resolve the discrepancy with "5d9"; although not with "0xf9". The thing that I consider "weird" and that I would really love to see addressed in a future version of PHP is that the increment of strings only works with a-z|A-Z while there are a lot of other alphabets where that should work similar. See https://3v4l.org/k0Nti for such an example. Incrementing a *string* is something that people should only do when they know what they are doing. That numeric strings are incremented one way and other strings another one is indeed something that can irritate people. And due to the missing type-system in former times it made sense. But given the by now available type-system using a "sane" increment could be as easy as `++(int)$var`. That way it is clear that whatever is in the variable $var should be treated as integer (or float) and be incremented after the conversion That way the already existing feature - it is clearly specified in the documentation and seems to be specified there for the last 20+ years - would stay the same while still allowing people to easily make sure that the increment way they expect is used. Yes! That would mean that `$i = "9"; echo ++$i` would output `A`, whereas `echo ++(int)$i` would output `10`. But I find that very intuitive and sane. Just my 0.02€ Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On 23/01/2023 14:06, G. P. B. wrote: However, the whole point of this RFC is to*remove* cognitive burden for developers, so they don't even need to be aware of this "feature" and not get surprised when it kicks in. Moreover, by your logic, you wouldn't care if we removed support for alphanumeric strings and only let the PERL increment kick in for purely alphabetical. While convenient for you, someone might actually use this feature on alphanumeric strings, and we're back to "why is my use case being removed while that other just as weird one remains". I make no judgement on alphanumeric strings, other than I can't see any use case for it myself, so I won't allow my objection be considered hypocritical; and your definition of my use case as "weird" is highly judgemental. Bijective numeration using the letters of the alphabet has a long and ancient tradition, pre-dating our modern numeric Hindu-Arabic system using base 10 for place/value notation by many centuries. The Abjadi system used the 28 letters of the Arabic alphabet; similarly the ancient Greeks and Hebrews, the Armenians; by Russia until the early 18th Century (each culture using their own alphabet). It's ironic that the Romans used a very different system, even though our modern western alphabet is based on the Roman alphabet. These civilisations didn't consider their alphabetic numeral system "weird". How many of the irregularities and idiosyncracies of alphanumeric strings could be resolved by not trying to cast them as a numeric value before increment/decrement; but by treating them consistently as strings? It would resolve the discrepancy with "5d9"; although not with "0xf9". -- Mark Baker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On Fri, 20 Jan 2023 at 19:44, Jordan LeDoux wrote: > I don't see a section in the RFC about JIT or anything related to OpCache, > but I know from experience with the Operator Overloads RFC that there are > several architecture specific assembly optimizations for ++ and --. Have > these been considered, and how will they be impacted? > The only assembly specific code is for integer increments/decrements, as those are not affected by this RFC there is no impact to them. Best regards, George P. Banyard
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On Fri, 20 Jan 2023 at 18:28, Mark Baker wrote: > The documentation page consistently uses the word Increment and > Decrement, not Add 1 and Subtract 1. > > Developers who read the documentation should be aware of the Perl > convention when dealing with alphabetic strings, and should expect that > behaviour. Alphanumeric strings are certainly more problematic, less > well documented, and less well understood, and I'll agree that they're > inconsistent in their behaviour. > The PHP documentation has never been the source of truth about the PHP implementation, if it was dynamics properties should have been removed without any notice as until them being deprecated there was no documentation. So arguing *something* should behave a certain way because the docs are written in a certain way holds no value to me. The state of the PHP docs could certainly be improved, as it is blatantly lying at various core sections. However, the whole point of this RFC is to *remove* cognitive burden for developers, so they don't even need to be aware of this "feature" and not get surprised when it kicks in. Moreover, by your logic, you wouldn't care if we removed support for alphanumeric strings and only let the PERL increment kick in for purely alphabetical. While convenient for you, someone might actually use this feature on alphanumeric strings, and we're back to "why is my use case being removed while that other just as weird one remains". I even went initially for such a proposal (see previous revision [1]), however, I realized this provides minimal benefit as it doesn't reduce at all the cognitive burden or the overall design specification of the language. > Deprecating the Increment operator for strings will create extra work > for me, will affect many of the users of my library, and I'm certain it > will also have a performance impact on the library (replacing that > operation with a more expensive function call for alpha increments, but > still having the operation for numeric increments). So yes, I am willing > to die on this hill because that deprecation will have a very direct and > adverse affect on my work. > If the issue is about performance, it is possible to enhance the optimizer to inline those two functions (something the optimizer already attempts to do for userland functions [2]). The other aspect goes back to the typical conundrum: Do we think PHP is in decline? - If yes, then not doing breaking changes and catering to legacy projects is definitely the course of action to take. - If no, improving PHP for the next generation of developers and software, so that it is easier to learn and reason about, should be the course of action to take. As I personally think we are in the second situation, that's why I'm tackling this subject in this manner. It's the same belief that made us deprecate dynamic properties, convert warnings to Errors, etc. Now, if we are in the former case, then you are totally justified, and I probably should find another job as I see no point in not improving the overall language semantics. George P. Banyard [1] https://wiki.php.net/rfc/saner-inc-dec-operators?rev=1669977388 [2] See zend_try_inline_call() function
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On Tue, Jan 17, 2023 at 6:28 AM G. P. B. wrote: > Hello Internals, > > I would like to start the discussion on the Path to Saner > Increment/Decrement operators RFC: > https://wiki.php.net/rfc/saner-inc-dec-operators > > The goal of this RFC is to reduce language complexity by making $v++ behave > like $v += 1 and $v-- behave like $v -= 1; > > I am expecting the contentious part of the proposal to be the deprecation > of the PERL string increment feature to achieve the aforementioned goal. > However, I believe the benefits of aligning the behaviour of the > increment/decrement operators with addition/subtraction are larger than > keeping support for the PERL increment, which in its current state has > various shortcomings. > > Best regards, > > George P. Banyard > I don't see a section in the RFC about JIT or anything related to OpCache, but I know from experience with the Operator Overloads RFC that there are several architecture specific assembly optimizations for ++ and --. Have these been considered, and how will they be impacted? Jordan
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On Fri, Jan 20, 2023, at 11:43 AM, G. P. B. wrote: > In any case, I've updated the RFC to version 0.3, [3] with a whole section > about the current behaviour of the PERL increment implementation in PHP, a > native implementation of str_increment() and str_decrement() that handles > strings that can be interpreted as numbers written in scientific notation. > It also changes the timeline slightly, as this seems the preferred course > of action. This seems like a reasonable plan to me, thanks! --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On 20/01/2023 19:48, Kamil Tekiela wrote:
I don't think it's such a huge issue as you make it to be. The
documentation states this only as an alternative:
https://phpspreadsheet.readthedocs.io/en/latest/topics/accessing-cells/#looping-through-cells-using-indexes
It also mentions the pitfalls. I doubt many users would prefer that
"alternative" given that the recommended way is simpler and does the same
thing.
I also don't think that performance would come into play here. Any
difference would be insignificant.
I believe that the benefits of the deprecation outweigh any potential extra
work the developers may have.
I beg to differ. Having done a lot of work last year recommending the
deprecation of using of column indexes (1,2,3,etc) in favour of
addresses ('A', 'B', 'C', etc) to more closely match with Excel's
layout; and knowing how much the codebase uses alpha column incrementing
internally, I'm aware of how much an issue it is.
I'd prefer if developers using PhpSpreadsheet used the built-in
iterators, and Im in the middle of writing a post on the benefits of
doing just that; but "under the hood" alpha column names are used, not
numeric indexes'; so a lot of the "under the hood" code uses ++ and --
with row numbers and column addresses.
And replacing any PHP operator with a function call is always going to
be less performant.
The benefits of this deprecation seem to be making ++ and -- consistent
by making them little more than a syntactic sugar for numeric values
only; I'm afraid I don't see that as a benefit; but as a retrograde
step, and not the same as making ++ and -- consistent.
--
Mark Baker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
I don't think it's such a huge issue as you make it to be. The documentation states this only as an alternative: https://phpspreadsheet.readthedocs.io/en/latest/topics/accessing-cells/#looping-through-cells-using-indexes It also mentions the pitfalls. I doubt many users would prefer that "alternative" given that the recommended way is simpler and does the same thing. I also don't think that performance would come into play here. Any difference would be insignificant. I believe that the benefits of the deprecation outweigh any potential extra work the developers may have.
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On 20/01/2023 18:43, G. P. B. wrote: That's a strange hill to die on, most people would expect that those operators do indeed behave like Add1 and Sub1, and clearly you are not having any issue with making -- act like Sub1. It isn't so strange, when you consider that an OS library like PhpSpreadsheet with over 100million installs makes extensive use of alpha and numeric increment (not alphanumeric); and I dearly wish that PHP had implemented the decrement operator for alpha strings as well, because that would have allowed me to simplify the codebase even further; so I would prefer if -- acted like a decrement for alpha strings, and not simply as a Sub1 for numerics. The documentation page consistently uses the word Increment and Decrement, not Add 1 and Subtract 1. Developers who read the documentation should be aware of the Perl convention when dealing with alphabetic strings, and should expect that behaviour. Alphanumeric strings are certainly more problematic, less well documented, and less well understood, and I'll agree that they're inconsistent in their behaviour. Deprecating the Increment operator for strings will create extra work for me, will affect many of the users of my library, and I'm certain it will also have a performance impact on the library (replacing that operation with a more expensive function call for alpha increments, but still having the operation for numeric increments). So yes, I am willing to die on this hill because that deprecation will have a very direct and adverse affect on my work. -- Mark Baker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On Thu, 19 Jan 2023 at 00:23, Mark Baker wrote:
>
> On 18/01/2023 21:25, G. P. B. wrote:
> >> I would like to start the discussion on the Path to Saner
> >> Increment/Decrement operators RFC:
> >> https://wiki.php.net/rfc/saner-inc-dec-operators
> >>
> >> The goal of this RFC is to reduce language complexity by making $v++
> >> behave like $v += 1 and $v-- behave like $v -= 1;
> > If that is the goal, then I would agree with this RFC.
> >
> > However, changing the PERL string increment feature does not IMO fit
> > into that goal, and it also a useful*feature*. On that base I would
> > vote against this. And I suspect many others would as well.
>
> However, the ++ and -- are the "Increment" and "Decrement" operators,
> not the Add1 and Subtract1 operators; while they behave in that way when
> used with variables containing numeric values, they are special
> operators and not simply a syntactic sugar for +=1 and -=1. As long as
> their behaviour is consistent, and definition of what "Increment" and
> "Decrement" mean is clearly defined for different datatypes, then I feel
> that the PERL-style alpha string increment has enough valid use cases to
> justify itself.
>
That's a strange hill to die on, most people would expect that those
operators do indeed behave like Add1 and Sub1, and clearly you are not
having any issue with making -- act like Sub1.
There is even a user note on the manual page from 21y ago where someone was
expecting booleans to be incremented. [1]
Moreover, the alphanumeric string increment feature is fundamentally broken
and unsound due to the simple fact that PHP supports converting numeric
strings written in scientific notation to float.
And this behaviour of casting a numeric string in scientific notation
*always* takes precedent over the alphanumeric increment.
The following code samples show this perfectly:
$s = "5d9";
var_dump(++$s); // string(3) "5e0"
var_dump(++$s); // float(6)
$s = "5e9";
var_dump(++$s); // float(51)
var_dump(++$s); // float(52)
Behaviour that *also* has a user note on the manual page. [2]
It is possible to have a sound implementation of it in userland, via the
following function:
function polyfill(string $s): string {
if (is_numeric($s)) {
$offset = stripos($s, 'e');
if ($offset !== false) {
/* Using increment operator would cast the string to float
* Therefore we manually increment it to convert it to an
"f"/"F" that doesn't get affected */
$c = $s[$offset];
$c++;
$s[$offset] = $c;
$s++;
$s[$offset] = match ($s[$offset]) {
'f' => 'e',
'F' => 'E',
'g' => 'f',
'G' => 'F',
};
return $s;
}
}
return ++$s;
}
> We might also discuss consistency of datatype changes when these
> operators are used.
>
> $a = PHP_INT_MAX;
>
> ++$a;
>
> or
>
> $a = '10';
>
> ++$a;
>
> both change the datatype of $a; which isn't documented behaviour either.
>
Those are just "regular" well documented type coercions due to addition and
int to float promotions.
And yes, the PHP documentation could be better, but no one is paid to work
on it.
However, it turns out that I only work part-time for The PHP Foundation,
and therefore I am available to be hired to do some technical writing for
the PHP Documentation.
(If anyone does want to take me up on this offer, do feel free to email me).
In any case, I've updated the RFC to version 0.3, [3] with a whole section
about the current behaviour of the PERL increment implementation in PHP, a
native implementation of str_increment() and str_decrement() that handles
strings that can be interpreted as numbers written in scientific notation.
It also changes the timeline slightly, as this seems the preferred course
of action.
Best regards,
George P. Banyard
[1] https://www.php.net/manual/en/language.operators.increment.php#16149
[2] https://www.php.net/manual/en/language.operators.increment.php#109621
[3] https://wiki.php.net/rfc/saner-inc-dec-operators
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On 19.01.2023 at 01:23, Mark Baker wrote: > However, the ++ and -- are the "Increment" and "Decrement" operators, > not the Add1 and Subtract1 operators; while they behave in that way when > used with variables containing numeric values, they are special > operators and not simply a syntactic sugar for +=1 and -=1. As long as > their behaviour is consistent, and definition of what "Increment" and > "Decrement" mean is clearly defined for different datatypes, then I feel > that the PERL-style alpha string increment has enough valid use cases to > justify itself. I understand your point, but also understand why increment/decrement operations can be seen as adding/subtracting 1 (the current documentation is actually pretty close to that interpretation). I'm not sure which interpretation I'd prefer. > We might also discuss consistency of datatype changes when these > operators are used. > > $a = PHP_INT_MAX; > > ++$a; > > or > > $a = '10'; > > ++$a; > > both change the datatype of $a; which isn't documented behaviour either. Well, that is the usual type juggling, but is indeed not properly document, from what I can tell (the "type juggling" page doesn't mention increment/decrement, and the "incrementing/decrementing operators" page doesn't mention the type juggling). -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On 18/01/2023 21:25, G. P. B. wrote: I would like to start the discussion on the Path to Saner Increment/Decrement operators RFC: https://wiki.php.net/rfc/saner-inc-dec-operators The goal of this RFC is to reduce language complexity by making $v++ behave like $v += 1 and $v-- behave like $v -= 1; If that is the goal, then I would agree with this RFC. However, changing the PERL string increment feature does not IMO fit into that goal, and it also a useful*feature*. On that base I would vote against this. And I suspect many others would as well. However, the ++ and -- are the "Increment" and "Decrement" operators, not the Add1 and Subtract1 operators; while they behave in that way when used with variables containing numeric values, they are special operators and not simply a syntactic sugar for +=1 and -=1. As long as their behaviour is consistent, and definition of what "Increment" and "Decrement" mean is clearly defined for different datatypes, then I feel that the PERL-style alpha string increment has enough valid use cases to justify itself. We might also discuss consistency of datatype changes when these operators are used. $a = PHP_INT_MAX; ++$a; or $a = '10'; ++$a; both change the datatype of $a; which isn't documented behaviour either. -- Mark Baker
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On Wed, Jan 18, 2023, at 2:25 PM, G. P. B. wrote:
> On Wed, 18 Jan 2023 at 16:03, Levi Morrison
> wrote:
>
>> It seems to me that if you truly want to clean up this specific part
>> of the language, you are going to have to play the long game:
>> 1. New functions are added for the perl behavior of string increment
>> and decrement. No warnings are given in code, but call-outs are made
>> in upgrading and other documentation about this behavior changing.
>> Note that in the past I would have used an E_STRICT for this, but
>> people seem opposed to adding new E_STRICT warnings.
>> 2. In the next minor version, we add a warning about the behavior
>> when string increment/decrement is used.
>> 3. In the next major version, we finally clean up the behavior.
>>
>> But this gets muddy if we do PHP 8.3 for step 1, and then we decide to
>> go for PHP 9.0 instead of 8.4, and it messes with the "ideal" cycle.
>>
>> Note that I support this sort of plan, and would support it for
>> cleaning up many other parts of PHP as well. It's just unfortunate it
>> takes so long, but that's how it goes sometimes :/
>
>
> I don't think we need such a long timeline because the function is easily
> poly filled.
> Moreover, if people jump a version in an upgrade, they are still going to
> immediately receive a warning/deprecation.
> But if such a timeline is preferred, I do not mind changing it.
>
> On Wed, 18 Jan 2023 at 18:33, Alex Wells wrote:
>
>> Classes and methods is the expected way of implementing standard library in
>> an OO language. New APIs (such as the new Random api) use OO instead of
>> functions and it makes more sense to use OO in this case too: there's
>> likely a place for other methods too, like toBase(int $otherBase) etc. It
>> would also be possible to use overloaded operators if needed.
>
>
> Until we have strings that can invoke methods, I don't see the point of
> having an OO API.
> PHP is a multi paradigm language, and creating a class with two methods
> seems very useless to me.
> OOP is favoured in PHP because using functions is just an overall terrible
> experience that needs improvements, but using functional patterns is
> totally doable (and can produce elegant code) in PHP.
>
> George P. Banyard
I agree that adding a str_increment() function and then (later) deprecating and
removing the ++ functionality is the way to go. I defer to George if it makes
sense to fix the other parts of ++ now and wait for 9 for string-incrementing,
or just wait and get rid of them all at once.
While str_increment() is less ergonomic than ++, I think the improved type
consistency is worth it. And it's trivial to wrap up into a generator if one
wants something shorter:
function cols(string $s): \Generator
{
while (true) {
$s = str_increment($s);
yield $s;
}
}
$it = cols('A');
$it->next(); // gives B
And that can be made parallel with something on the number side if you really
want.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On Wed, Jan 18, 2023 at 10:09 PM Claude Pache
wrote:
>
>
> Le 18 janv. 2023 à 19:33, Alex Wells a écrit :
>
> Classes and methods is the expected way of implementing standard library
> in an OO language. New APIs (such as the new Random api) use OO instead of
> functions and it makes more sense to use OO in this case too: there's
> likely a place for other methods too, like toBase(int $otherBase) etc. It
> would also be possible to use overloaded operators if needed.
>
>
> Fortunately, PHP is not (yet) a language where every problem requires the
> use and manipulation of objects implementing a generalised and unified
> solution. I guess that the OO way of writing:
>
> ```php
> function next_alpha_id(): string {
> static $x = 'zz';
> return ++$x;
> }
>
> function next_num_id(): int {
> static $x = 0;
> return ++$x;
> }
>
> $my_id = next_alpha_id();
> $my_other_id = next_num_id();
> ```
>
> would resemble to the following, except that `mixed` should be replaced by
> the use of generics. For brevity, I left the mandatory interfaces as
> exercise to the reader.
>
> ```php
> class IdGenerator {
>
> protected mixed $current;
>
> public function __construct(
> protected readonly IdGeneratorType $type
> , protected readonly IdGeneratorDirection $direction
> , mixed $start
> ) {
> $this->current = $start;
> }
>
> public function next(): mixed {
> // implementation...
> }
>
> }
>
> enum IdGeneratorType {
> case alphabetic;
> case numeric;
> }
>
> enum IdGeneratorDirection {
> case positive;
> case negative;
> }
>
>
>
> final class StandardGlobalAlphabeticIdGenerator {
>
> private static IdGenerator $id_generator;
>
> public static function get(): IdGenerator {
> return self::$id_generator ?? new IdGenerator(
> type: IdGeneratorType::alphabetic
> , direction: IdGeneratorDirection::positive
> , start: 'aaa'
> );
> }
>
> }
>
> final class StandardGlobalNumericIdGenerator {
>
> private static IdGenerator $id_generator;
>
> public static function get(): IdGenerator {
> return self::$id_generator ?? new IdGenerator(
> type: IdGeneratorType::numeric
> , direction: IdGeneratorDirection::positive
> , start: 1
> );
> }
>
> }
>
>
> $my_id = StandardGlobalAlphabeticIdGenerator::get()->next();
> $my_other_id = StandardGlobalNumericIdGenerator::get()->next();
> ```
>
> —Claude
>
>
You've overcomplicated your example, but the truth is that there's
sometimes a reason behind the complexity you might see. In this case your
functions will work right until you need two independent sequences, or you
need a backwards direction, or you need a sequence that can be seeded with
a "starting point". The point is not to have the "OO way" because someone
likes it, the point is to provide more flexibility, one that is likely to
be needed down the road.
In this case, a class like Number that accepts a specific $base in the
constructor will not hurt. There are definitely use cases for custom base
numbers as mentioned above and a class is just a better way of doing it
than trying to combine multiple concepts (base-10 ints, text strings and
custom base numbers) under one or two types and a bunch of functions on
top.
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On Wed, 18 Jan 2023 at 14:35, Björn Larsson wrote: > Since the alpanumeric_decrement RFC was rejected january 2014 9 years ago, > could it be an option to bring it up again in conjunctione with your RFC? > > Maybe the added value of your RFC could swing the opinion. I mean there has > been RFC's that required multiple tries to fly. > Possibly, and I could wait for the result of such an RFC, but I do not intend on pushing this forward. On Wed, 18 Jan 2023 at 15:32, Derick Rethans wrote: > On Tue, 17 Jan 2023, G. P. B. wrote: > > > I would like to start the discussion on the Path to Saner > > Increment/Decrement operators RFC: > > https://wiki.php.net/rfc/saner-inc-dec-operators > > > > The goal of this RFC is to reduce language complexity by making $v++ > > behave like $v += 1 and $v-- behave like $v -= 1; > > If that is the goal, then I would agree with this RFC. > > However, changing the PERL string increment feature does not IMO fit > into that goal, and it also a useful *feature*. On that base I would > vote against this. And I suspect many others would as well. > I do not understand how this does *not* fit into that goal. $s = "a10"; $s += 1; var_dump($s); Results in a TypeError whereas $s = "a10"; $s++; var_dump($s); Results in string(3) "a11" Therefore, $s++ does not behave like $s += 1; and thus in scope. Is there a way to avoid this single useful feature from being > deprecated, while to good parts of this RFC stay? > Yes, but at that point, I don't see why we should unify the behaviour if it is going to remain inconsistent. Might as well make incrementing on bool, and decrementing null a TypeError in PHP 9 to make it stricter. > I am also unsure as how much actual breakage this would cause, and > before this gets up to a vote, I would like to see how bad (or not) this > would affect already existing code bases. > Fair point, I can try and run Nikita's script on the top composer packages, but that won't show the state of private codebases. On Wed, 18 Jan 2023 at 16:03, Levi Morrison wrote: > It seems to me that if you truly want to clean up this specific part > of the language, you are going to have to play the long game: > 1. New functions are added for the perl behavior of string increment > and decrement. No warnings are given in code, but call-outs are made > in upgrading and other documentation about this behavior changing. > Note that in the past I would have used an E_STRICT for this, but > people seem opposed to adding new E_STRICT warnings. > 2. In the next minor version, we add a warning about the behavior > when string increment/decrement is used. > 3. In the next major version, we finally clean up the behavior. > > But this gets muddy if we do PHP 8.3 for step 1, and then we decide to > go for PHP 9.0 instead of 8.4, and it messes with the "ideal" cycle. > > Note that I support this sort of plan, and would support it for > cleaning up many other parts of PHP as well. It's just unfortunate it > takes so long, but that's how it goes sometimes :/ I don't think we need such a long timeline because the function is easily poly filled. Moreover, if people jump a version in an upgrade, they are still going to immediately receive a warning/deprecation. But if such a timeline is preferred, I do not mind changing it. On Wed, 18 Jan 2023 at 18:33, Alex Wells wrote: > Classes and methods is the expected way of implementing standard library in > an OO language. New APIs (such as the new Random api) use OO instead of > functions and it makes more sense to use OO in this case too: there's > likely a place for other methods too, like toBase(int $otherBase) etc. It > would also be possible to use overloaded operators if needed. Until we have strings that can invoke methods, I don't see the point of having an OO API. PHP is a multi paradigm language, and creating a class with two methods seems very useless to me. OOP is favoured in PHP because using functions is just an overall terrible experience that needs improvements, but using functional patterns is totally doable (and can produce elegant code) in PHP. George P. Banyard
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
> Le 18 janv. 2023 à 19:33, Alex Wells a écrit :
>
> Classes and methods is the expected way of implementing standard library in
> an OO language. New APIs (such as the new Random api) use OO instead of
> functions and it makes more sense to use OO in this case too: there's likely
> a place for other methods too, like toBase(int $otherBase) etc. It would also
> be possible to use overloaded operators if needed.
Fortunately, PHP is not (yet) a language where every problem requires the use
and manipulation of objects implementing a generalised and unified solution. I
guess that the OO way of writing:
```php
function next_alpha_id(): string {
static $x = 'zz';
return ++$x;
}
function next_num_id(): int {
static $x = 0;
return ++$x;
}
$my_id = next_alpha_id();
$my_other_id = next_num_id();
```
would resemble to the following, except that `mixed` should be replaced by the
use of generics. For brevity, I left the mandatory interfaces as exercise to
the reader.
```php
class IdGenerator {
protected mixed $current;
public function __construct(
protected readonly IdGeneratorType $type
, protected readonly IdGeneratorDirection $direction
, mixed $start
) {
$this->current = $start;
}
public function next(): mixed {
// implementation...
}
}
enum IdGeneratorType {
case alphabetic;
case numeric;
}
enum IdGeneratorDirection {
case positive;
case negative;
}
final class StandardGlobalAlphabeticIdGenerator {
private static IdGenerator $id_generator;
public static function get(): IdGenerator {
return self::$id_generator ?? new IdGenerator(
type: IdGeneratorType::alphabetic
, direction: IdGeneratorDirection::positive
, start: 'aaa'
);
}
}
final class StandardGlobalNumericIdGenerator {
private static IdGenerator $id_generator;
public static function get(): IdGenerator {
return self::$id_generator ?? new IdGenerator(
type: IdGeneratorType::numeric
, direction: IdGeneratorDirection::positive
, start: 1
);
}
}
$my_id = StandardGlobalAlphabeticIdGenerator::get()->next();
$my_other_id = StandardGlobalNumericIdGenerator::get()->next();
```
—Claude
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On 18/01/2023 17:10, Craig Francis wrote: I agree that some of the incrementing behaviour can be a bit weird, and I would be happy to see those be deprecated/removed; but I worry that the A, B, ..., Z, AA, AB, etc is something that works well today, and is likely to be tricky to find/replace with a new function in all existing code. Replacing the use of an existing operator with a new function call, but only in certain circumstances (for alpha increments but not for numeric increments) would also be a pain; we'd have to examine every instance of ++ use to see what datatype it was being used on (SA tools won't necessarily help with that); and when looping over Excel rows and columns it would seem strange allowing the ++ operator for rows, but having to use a function call for columns when all previous code also used ++. -- Mark Baker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On 18/01/2023 18:27, Kamil Tekiela wrote:
When I read the RFC I was a little sceptical about the deprecation of
string increment functionality. It's something I used in the past and I see
no easy upgrade path. However, after reading this thread and thinking it
over, I realize that deprecation is the right way to go. Someone said that
it's useful when working with Excel. Excel uses bijective base-26 system.
PHP does not. I cannot even explain what logic governs PHP string increment
functionality.
The logic is actually fairly straightforward if you consider breaking
the original string into blocks of alpha, numeric and non-alphameric
characters; so a string like 'C-37AZ99' would be broken into five blocks
of characters ('C', '-', '37', 'AZ' and '99').
Start with the rightmost block, but only if its alpha or numeric: the
process will never increment any block of characters that is non-alphameric.
Increment the current block.
If that increment would result in an overflow (extending the size of
that block) and there is another block to the "left" in the chain of
blocks, then that block is reset to its "base" value (discard the
overflow character), and the same process is repeated for incrementing
the next block in the chain.
The process terminates when there are no more blocks in the chain, or
when the process encounters a non-alphameric block.
The string is then "glued" back together again for the return.
In this regard, when a block is alpha characters, then the increment
behaviour matches "Excel's bijective base-26".
--
Mark Baker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On Wed, Jan 18, 2023, 19:57 Claude Pache wrote:
>
>
> > Le 18 janv. 2023 à 18:27, Kamil Tekiela a écrit :
> >
> > Strings should not be incrementable unless they are numeric strings. The
> > current "feature" is more like a bug from xkcd comic.
> https://xkcd.com/1172/
> >
> > But as there is a real need for a similar functionality, for example when
> > working with Excel, I would propose to add a class into the language that
> > is able to calculate and iterate any bijective base system. It needs to
> > have a clear functional spec and should support both increment/decrement
> > operators as well as iterators. I see this as the only way out of this
> > mess. This RFC needs to pass, but it cannot pass without an alternative
> for
> > people who actually use this "feature".
>
> For those that lack imagination about possible use cases, here is mine:
> generating unique (in the scope of the request) alphabetic ids:
>
> function nextid(): string {
> static $id = 'zz';
> return ++$id;
> }
>
> But no over-engineering please: no class and no decrement equivalent (the
> latter could be added in a separate RFC if it is really deemed useful),
> just a plain function that replicate the current behaviour for strings of
> the form /^[A-Za-z0-9]*$/, minus the bugs around the peculiar notion of
> “numeric string” (e.g., "9E1" equivalent to 90).
>
> —Claude
Classes and methods is the expected way of implementing standard library in
an OO language. New APIs (such as the new Random api) use OO instead of
functions and it makes more sense to use OO in this case too: there's
likely a place for other methods too, like toBase(int $otherBase) etc. It
would also be possible to use overloaded operators if needed.
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
> Le 18 janv. 2023 à 18:27, Kamil Tekiela a écrit :
>
> Strings should not be incrementable unless they are numeric strings. The
> current "feature" is more like a bug from xkcd comic. https://xkcd.com/1172/
>
> But as there is a real need for a similar functionality, for example when
> working with Excel, I would propose to add a class into the language that
> is able to calculate and iterate any bijective base system. It needs to
> have a clear functional spec and should support both increment/decrement
> operators as well as iterators. I see this as the only way out of this
> mess. This RFC needs to pass, but it cannot pass without an alternative for
> people who actually use this "feature".
For those that lack imagination about possible use cases, here is mine:
generating unique (in the scope of the request) alphabetic ids:
function nextid(): string {
static $id = 'zz';
return ++$id;
}
But no over-engineering please: no class and no decrement equivalent (the
latter could be added in a separate RFC if it is really deemed useful), just a
plain function that replicate the current behaviour for strings of the form
/^[A-Za-z0-9]*$/, minus the bugs around the peculiar notion of “numeric string”
(e.g., "9E1" equivalent to 90).
—Claude
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
I like this proposal and I support making the language consistent. I wasn't aware there were so many inconsistencies with increment/decrement operators. When I read the RFC I was a little sceptical about the deprecation of string increment functionality. It's something I used in the past and I see no easy upgrade path. However, after reading this thread and thinking it over, I realize that deprecation is the right way to go. Someone said that it's useful when working with Excel. Excel uses bijective base-26 system. PHP does not. I cannot even explain what logic governs PHP string increment functionality. ``` $s = "az"; var_dump(++$s); // string(2) "ba" $s = "a9"; var_dump(++$s); // string(2) "b0" $s = "99"; var_dump(++$s); // int(100) $s = "zZ"; var_dump(++$s); // string(3) "aaA" $s = "9D9"; var_dump(++$s); // string(3) "9E0" $s = "9E0"; var_dump(++$s); // float(10) $s = "CHEAP BED"; var_dump(++$s); // string(9) "CHEAP BEE" ``` Strings should not be incrementable unless they are numeric strings. The current "feature" is more like a bug from xkcd comic. https://xkcd.com/1172/ But as there is a real need for a similar functionality, for example when working with Excel, I would propose to add a class into the language that is able to calculate and iterate any bijective base system. It needs to have a clear functional spec and should support both increment/decrement operators as well as iterators. I see this as the only way out of this mess. This RFC needs to pass, but it cannot pass without an alternative for people who actually use this "feature". The PHP manual says: "The increment/decrement operators only affect numbers and strings. Arrays, objects, booleans and resources are not affected. Decrementing null values has no effect too, but incrementing them results in 1." But that's not true. You cannot increment an array or resource as it would trigger an error. But incrementing false/true doesn't generate any errors. It's very inconsistent and misleading.
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On 18 January 2023 15:32:28 GMT, Derick Rethans wrote: >> The goal of this RFC is to reduce language complexity by making $v++ >> behave like $v += 1 and $v-- behave like $v -= 1; > >If that is the goal, then I would agree with this RFC. > >However, changing the PERL string increment feature does not IMO fit >into that goal I agree, *changing* its behaviour does not achieve that goal; only removing the behaviour (with an appropriate deprecation period and upgrade path) achieves the goal. (For completeness, the only other way to achieve the goal would be to add support for string increments to the += operator, and presumably also the + operator to avoid a different inconsistency. That is, make 'a' + 5 === 'f'. I don't think that's even worth considering, but it's the only other way to achieve consistency.) Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On 18 Jan 2023, at 12:22, G. P. B. wrote: > [...] > I appreciate being shown concrete cases about the useful ness of this > operation. > The reason I didn't go with adding support for decrementing alphanumeric > strings is that it was unanimously rejected. > However, if Rowan's suggestion of adding > string_increment()/string_decrement() with more rigorous behaviour (that we > can flesh out together) would be part of this proposal, would you be more > inclined to accept deprecating ++ from performing this feature? Hi George, I don't have a vote at the moment (I think I need one more RFC to pass)... but you might be able to convince me, I just like to know that breakages are really worth it, because my biggest issue is trying to get developers to upgrade their PHP installs (a lot are still on 7.4). I agree that some of the incrementing behaviour can be a bit weird, and I would be happy to see those be deprecated/removed; but I worry that the A, B, ..., Z, AA, AB, etc is something that works well today, and is likely to be tricky to find/replace with a new function in all existing code. At the moment I'd prefer Option 2 or 3, with the focus being on "tiding up the behaviour of the alphanumeric string to make it stricter and less error-prone." Craig -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
It seems to me that if you truly want to clean up this specific part of the language, you are going to have to play the long game: 1. New functions are added for the perl behavior of string increment and decrement. No warnings are given in code, but call-outs are made in upgrading and other documentation about this behavior changing. Note that in the past I would have used an E_STRICT for this, but people seem opposed to adding new E_STRICT warnings. 2. In the next minor version, we add a warning about the behavior when string increment/decrement is used. 3. In the next major version, we finally clean up the behavior. But this gets muddy if we do PHP 8.3 for step 1, and then we decide to go for PHP 9.0 instead of 8.4, and it messes with the "ideal" cycle. Note that I support this sort of plan, and would support it for cleaning up many other parts of PHP as well. It's just unfortunate it takes so long, but that's how it goes sometimes :/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
> Le 17 janv. 2023 à 15:28, G. P. B. a écrit : > > Hello Internals, > > I would like to start the discussion on the Path to Saner > Increment/Decrement operators RFC: > https://wiki.php.net/rfc/saner-inc-dec-operators Hi, Adding a `str_increment(...)` function that roughly replicates the current behaviour of `++$x` for non-numeric strings, is necessary and sufficient in order to have a simple and clear path forward for those that use the feature, thanks. (On the other hand, a `str_decrement(...)` equivalent is not useful for the scope of this RFC.) —Claude -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On Tue, 17 Jan 2023, G. P. B. wrote: > I would like to start the discussion on the Path to Saner > Increment/Decrement operators RFC: > https://wiki.php.net/rfc/saner-inc-dec-operators > > The goal of this RFC is to reduce language complexity by making $v++ > behave like $v += 1 and $v-- behave like $v -= 1; If that is the goal, then I would agree with this RFC. However, changing the PERL string increment feature does not IMO fit into that goal, and it also a useful *feature*. On that base I would vote against this. And I suspect many others would as well. Is there a way to avoid this single useful feature from being deprecated, while to good parts of this RFC stay? I am also unsure as how much actual breakage this would cause, and before this gets up to a vote, I would like to see how bad (or not) this would affect already existing code bases. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
Den 2023-01-18 kl. 13:22, skrev G. P. B.: On Tue, 17 Jan 2023 at 18:28, Mark Baker wrote: On 17/01/2023 17:28, Craig Francis wrote: I've seen this used a few times, e.g. starting with a numerical value (Passport number, NHS number, Social Security Number, Date of Birth 20230117), and the developer simply appends an incrementing letter on the end to get a unique reference; e.g. a person having multiple assessments... especially if it's more than 26 (A-Z), and you need to move to multiple letters, which `chr(90 + 1)` cannot help you with. Being able to increment alpha strings is incredibly useful when working with Excel spreadsheets (as I do on a daily basis), because the column Ids match this pattern; and I would hate to see this deprecated. Having to replicate that logic for traversing column Ids in userland code would be inconvenient (to say the least), would affect many of the users of my libraries, and would have a performance impact on my libraries. If anything, I'd rather like to see the decrement operator work with alpha strings as well for more consistency. I don't have the karma for a vote; but if I did then it would be a "No" for this alone, because I can see the problems that it will cause me and the users of my libraries. That said, I appreciate that incrementing some strings can be a bit unusual (e.g. "A9" to "B0", vs "A 9" to "A 0"). Agreed. While incrementing works in a very logical manner with mixed alphanumeric strings, it's not well documented behaviour, and most developers take a long time before they understand what it's actually doing. While there might be use cases for incrementing alphanumerics, I suspect that it would be better implemented in the business logic of an application, because the component parts of that string are likely to have business meaning; and also to provide better code readability. I appreciate being shown concrete cases about the useful ness of this operation. The reason I didn't go with adding support for decrementing alphanumeric strings is that it was unanimously rejected. However, if Rowan's suggestion of adding string_increment()/string_decrement() with more rigorous behaviour (that we can flesh out together) would be part of this proposal, would you be more inclined to accept deprecating ++ from performing this feature? I truly believe having $v++ behave like $v += 1 and $v-- behave like $v -= 1; is something to strive for *because* it allows us to remove one dedicated type juggling context people need to be aware of and simplifies the overall semantics of the language. Keeping support for string increments means that one cannot interchange $v++ and $v += 1 and that one needs to be aware about using it when a value might hold a string. As such, if it needs to remain its own type juggling context, the question is why not make it stricter by having it warn and then throw a TypeError on bool, reopening the can of worms that is the null handling between both operators and what to do with the empty string case. These questions are already answered by making those operators behave just like addition/subtraction. My order of preference for the semantics are as follows: 1. The behaviour described in the RFC (with or without function for string in/decrement) 2. (with a massive gap, but I could live with it) adding support for string decrements and tiding up the behaviour of the alphanumeric string to make it stricter and less error-prone. 3. The current asymmetry (again with a massive gap between this and option 2) But because option 2 seems out of the question due to the unanimous rejection of https://wiki.php.net/rfc/alpanumeric_decrement, the only viable options to me seem like 1 and 3. As I hate option 3 I am pushing for option 1 as I think it has various benefits. Since the alpanumeric_decrement RFC was rejected january 2014 9 years ago, could it be an option to bring it up again in conjunctione with your RFC? Maybe the added value of your RFC could swing the opinion. I mean there has been RFC's that required multiple tries to fly. Regards //Björn L -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On Tue, 17 Jan 2023 at 18:28, Mark Baker wrote: > On 17/01/2023 17:28, Craig Francis wrote: > > I've seen this used a few times, e.g. starting with a numerical value > (Passport number, NHS number, Social Security Number, Date of Birth > 20230117), and the developer simply appends an incrementing letter on the > end to get a unique reference; e.g. a person having multiple assessments... > especially if it's more than 26 (A-Z), and you need to move to multiple > letters, which `chr(90 + 1)` cannot help you with. > > Being able to increment alpha strings is incredibly useful when working > with Excel spreadsheets (as I do on a daily basis), because the column > Ids match this pattern; and I would hate to see this deprecated. Having > to replicate that logic for traversing column Ids in userland code would > be inconvenient (to say the least), would affect many of the users of my > libraries, and would have a performance impact on my libraries. If > anything, I'd rather like to see the decrement operator work with alpha > strings as well for more consistency. > > I don't have the karma for a vote; but if I did then it would be a "No" > for this alone, because I can see the problems that it will cause me and > the users of my libraries. > > > > That said, I appreciate that incrementing some strings can be a bit > unusual (e.g. "A9" to "B0", vs "A 9" to "A 0"). > > Agreed. While incrementing works in a very logical manner with mixed > alphanumeric strings, it's not well documented behaviour, and most > developers take a long time before they understand what it's actually > doing. While there might be use cases for incrementing alphanumerics, I > suspect that it would be better implemented in the business logic of an > application, because the component parts of that string are likely to > have business meaning; and also to provide better code readability. > I appreciate being shown concrete cases about the useful ness of this operation. The reason I didn't go with adding support for decrementing alphanumeric strings is that it was unanimously rejected. However, if Rowan's suggestion of adding string_increment()/string_decrement() with more rigorous behaviour (that we can flesh out together) would be part of this proposal, would you be more inclined to accept deprecating ++ from performing this feature? I truly believe having $v++ behave like $v += 1 and $v-- behave like $v -= 1; is something to strive for *because* it allows us to remove one dedicated type juggling context people need to be aware of and simplifies the overall semantics of the language. Keeping support for string increments means that one cannot interchange $v++ and $v += 1 and that one needs to be aware about using it when a value might hold a string. As such, if it needs to remain its own type juggling context, the question is why not make it stricter by having it warn and then throw a TypeError on bool, reopening the can of worms that is the null handling between both operators and what to do with the empty string case. These questions are already answered by making those operators behave just like addition/subtraction. My order of preference for the semantics are as follows: 1. The behaviour described in the RFC (with or without function for string in/decrement) 2. (with a massive gap, but I could live with it) adding support for string decrements and tiding up the behaviour of the alphanumeric string to make it stricter and less error-prone. 3. The current asymmetry (again with a massive gap between this and option 2) But because option 2 seems out of the question due to the unanimous rejection of https://wiki.php.net/rfc/alpanumeric_decrement, the only viable options to me seem like 1 and 3. As I hate option 3 I am pushing for option 1 as I think it has various benefits. Moreover, I do not want to split this into its own proposal (deprecating string increments/figuring out what to do with them) as I feel it will make any attempt to improve the situation harder. Best regards, George P. Banyard
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On 17/01/2023 14:28, G. P. B. wrote:
I would like to start the discussion on the Path to Saner
Increment/Decrement operators RFC:
https://wiki.php.net/rfc/saner-inc-dec-operators
The goal of this RFC is to reduce language complexity by making $v++ behave
like $v += 1 and $v-- behave like $v -= 1;
Hi George,
Thanks for tackling this. I heartily agree with the aims of this RFC;
the current situation is a weird mess of special cases, most of which
are justified only by "it's always been that way".
I am expecting the contentious part of the proposal to be the deprecation
of the PERL string increment feature to achieve the aforementioned goal.
As Craig and Mark point out, this functionality does have legitimate
uses, and I am generally of the opinion that deprecations should either
be of broken functionality (as is often the case when upgrading Warnings
to Errors) or come with specific instructions for a replacement.
Perhaps therefore we should introduce a new function, string_inc, as the
official migration path for deliberate use of this feature. This could
give the same result as the current increment operator for supported
cases, but throw an Error for cases that would currently be left
unchanged. A polyfill using the existing operator on old versions would
look something like this:
function string_inc(string $input): string {
$output = $input;
@ ++$output;
if ( $input === $output ) {
throw new Error("Unsupported input to string_inc: '$input'");
}
return $output;
}
Without the need to interact with other types or existing behaviour, I
think an accompanying string_dec would also be less controversial than
previous RFCs. Ambiguous cases like string_dec("a"), string_dec(""), and
string_dec("0") could simply throw an Error.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On 17/01/2023 17:28, Craig Francis wrote: I've seen this used a few times, e.g. starting with a numerical value (Passport number, NHS number, Social Security Number, Date of Birth 20230117), and the developer simply appends an incrementing letter on the end to get a unique reference; e.g. a person having multiple assessments... especially if it's more than 26 (A-Z), and you need to move to multiple letters, which `chr(90 + 1)` cannot help you with. Being able to increment alpha strings is incredibly useful when working with Excel spreadsheets (as I do on a daily basis), because the column Ids match this pattern; and I would hate to see this deprecated. Having to replicate that logic for traversing column Ids in userland code would be inconvenient (to say the least), would affect many of the users of my libraries, and would have a performance impact on my libraries. If anything, I'd rather like to see the decrement operator work with alpha strings as well for more consistency. I don't have the karma for a vote; but if I did then it would be a "No" for this alone, because I can see the problems that it will cause me and the users of my libraries. That said, I appreciate that incrementing some strings can be a bit unusual (e.g. "A9" to "B0", vs "A 9" to "A 0"). Agreed. While incrementing works in a very logical manner with mixed alphanumeric strings, it's not well documented behaviour, and most developers take a long time before they understand what it's actually doing. While there might be use cases for incrementing alphanumerics, I suspect that it would be better implemented in the business logic of an application, because the component parts of that string are likely to have business meaning; and also to provide better code readability. -- Mark Baker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On 17 Jan 2023, at 14:28, G. P. B. wrote: > https://wiki.php.net/rfc/saner-inc-dec-operators > > The goal of this RFC is to reduce language complexity by making $v++ behave > like $v += 1 and $v-- behave like $v -= 1; > > I am expecting the contentious part of the proposal to be the deprecation > of the PERL string increment feature to achieve the aforementioned goal. Hi George, Just to confirm, you're suggesting the following would be broken: ``` $ref = 'A'; $ref++; var_dump($ref); // 'B' $ref = 'Z'; $ref++; var_dump($ref); // 'AA' $ref++; var_dump($ref); // 'AB' ``` I've seen this used a few times, e.g. starting with a numerical value (Passport number, NHS number, Social Security Number, Date of Birth 20230117), and the developer simply appends an incrementing letter on the end to get a unique reference; e.g. a person having multiple assessments... especially if it's more than 26 (A-Z), and you need to move to multiple letters, which `chr(90 + 1)` cannot help you with. That said, I appreciate that incrementing some strings can be a bit unusual (e.g. "A9" to "B0", vs "A 9" to "A 0"). Craig -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
