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
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
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
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
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
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
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
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 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
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
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
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
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 -=
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
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
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
> 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
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
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
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
> 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
>
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
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
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
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
> 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
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--
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
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
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 -=
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
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
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
33 matches
Mail list logo
