Den 2023-01-18 kl. 13:22, skrev G. P. B.:
On Tue, 17 Jan 2023 at 18:28, Mark Baker <m...@demon-angel.eu> 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
