Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119328
MIME-Version: 1.0
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>
 <F0C029A9-76AF-459F-87AC-433770CE745C@gmail.com>
In-Reply-To: <F0C029A9-76AF-459F-87AC-433770CE745C@gmail.com>
Reply-To: autaut03@gmail.com
Date: Wed, 18 Jan 2023 20:33:10 +0200
Message-ID: <CABigaAXz+7g2moCjxRzpx_SZ=PdzzOvywmEw=0TKJmjXuSQEDg@mail.gmail.com>
To: Claude Pache <claude.pache@gmail.com>
Cc: Kamil Tekiela <tekiela246@gmail.com>, 
	PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002a851e05f28e0dea"
Subject: Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
From: autaut03@gmail.com (Alex Wells)

--0000000000002a851e05f28e0dea
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 18, 2023, 19:57 Claude Pache <claude.pache@gmail.com> wrote:

>
>
> > Le 18 janv. 2023 =C3=A0 18:27, Kamil Tekiela <tekiela246@gmail.com> a =
=C3=A9crit :
> >
> > Strings should not be incrementable unless they are numeric strings. Th=
e
> > 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 wh=
en
> > working with Excel, I would propose to add a class into the language th=
at
> > is able to calculate and iterate any bijective base system. It needs to
> > have a clear functional spec and should support both increment/decremen=
t
> > 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


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.

--0000000000002a851e05f28e0dea--