Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112464
MIME-Version: 1.0
References: <d1c4689e-9120-4e90-837c-a1b3eac63cd6@www.fastmail.com>
 <3c47b09a-5678-5a27-f482-114d0469cf4d@processus.org> <fd7d31bd-1170-4111-8fe3-f91c8d348b07@www.fastmail.com>
In-Reply-To: <fd7d31bd-1170-4111-8fe3-f91c8d348b07@www.fastmail.com>
Date: Mon, 7 Dec 2020 21:43:31 +0100
Message-ID: <CAJpLVh1uguAqMJ1-H=KgKbC-RimHrg-8Ap12XbPVzStwOnkDxg@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e16aa805b5e5e10d"
Subject: Re: [PHP-DEV] [RFC] Enumerations
From: olleharstedt@gmail.com (=?UTF-8?Q?Olle_H=C3=A4rstedt?=)

--000000000000e16aa805b5e5e10d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 5 Dec 2020, 15:43 Larry Garfield, <larry@garfieldtech.com> wrote:

> On Sat, Dec 5, 2020, at 3:26 AM, Pierre R. wrote:
> > Le 05/12/2020 =C3=A0 00:24, Larry Garfield a =C3=A9crit :
> > > Greetings, denizens of Internals!
> > >
> > > Ilija Tovilo and I have been working for the last few months on addin=
g
> support for enumerations and algebraic data types to PHP.  This is a
> not-small task, so we've broken it up into several stages.  The first
> stage, unit enumerations, are just about ready for public review and
> discussion.
> > >
> > > The overarching plan (for context, NOT the thing to comment on right
> now) is here: https://wiki.php.net/rfc/adts
> > >
> > > The first step, for unit enumerations, is here:
> > >
> > > https://wiki.php.net/rfc/enumerations
> > >
> > > There's still a few bits we're sorting out and the implementation is
> mostly done, but not 100% complete.  Still, it's far enough along to star=
t
> a discussion on and get broader feedback on the outstanding nits.
> > >
> > > I should note that while the design has been collaborative, credit fo=
r
> the implementation goes entirely to Ilija.  Blame for any typos in the RF=
C
> itself go entirely to me.
> > >
> > > *dons flame-retardant suit*
> > >
> > Another question, about match() behavior:
> >
> >  > This usage requires no modification of |match|. It is a natural
> > implication of the current functionality.
> >
> > May be this could be the time to have a "strict match", using enums, we
> > can "statically" guess if branches are missing (of course, whenever you
> > use default it valid to miss branches) - one thing I'd love is PHP to
> > throw a fatal error when compiling a match expression whose missing
> > branches, and not wait until runtime to fail.
>
> I think that would make a great follow-up, but it's out of scope for now.
> Having match statically know what the available types are when the variab=
le
> type isn't yet known (because it's in another file) is... I don't know ho=
w
> to do that.  That's a broad problem across PHP, frankly.  If we can figur=
e
> out a way to do so, I'd support adding it in the future.  (I can't speak
> for Ilija, but I suspect he would be on board as well.)
>

Static analysis can (should?) be taken care of by any of the tools
available for PHP. Wouldn't it be a waste of effort to try to include it in
the runtime parser as well?

>

--000000000000e16aa805b5e5e10d--