Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119327
Message-ID: <F0C029A9-76AF-459F-87AC-433770CE745C@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_A01A2FEE-2324-457E-87B0-9F0D6FE3C214"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\))
Date: Wed, 18 Jan 2023 18:57:15 +0100
In-Reply-To: <CAGBsUreK46-tg6XZmykPJx2ap-fnKbLs0=NsjwTntxbbFK2E-Q@mail.gmail.com>
Cc: internals@lists.php.net
To: Kamil Tekiela <tekiela246@gmail.com>
References: <CAFPFaMLtOAkRzTsqfdhvkZZ17JpUBg_WSQBpgVU6+xg-mLt2zA@mail.gmail.com>
 <alpine.DEB.2.23.453.2301181523100.23089@singlemalt.home.derickrethans.nl>
 <04288995-54CE-41A4-BFFD-A7CF72F16D3F@gmail.com>
 <CAGBsUreK46-tg6XZmykPJx2ap-fnKbLs0=NsjwTntxbbFK2E-Q@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
From: claude.pache@gmail.com (Claude Pache)

--Apple-Mail=_A01A2FEE-2324-457E-87B0-9F0D6FE3C214
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> Le 18 janv. 2023 =C3=A0 18:27, Kamil Tekiela <tekiela246@gmail.com> a =
=C3=A9crit :
>=20
> 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/
>=20
> 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 =3D '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 =E2=80=9Cnumeric string=E2=80=9D (e.g., "9E1" equivalent to =
90).

=E2=80=94Claude=

--Apple-Mail=_A01A2FEE-2324-457E-87B0-9F0D6FE3C214--