Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112705
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-ID: <631e6b07-415d-4d66-8826-cad4802ba4b3@www.fastmail.com>
In-Reply-To: 
 <CAEPJdum2C2RTrFmBunHBF9uUVge90JGmbAH=mJY0MD7e3uduNw@mail.gmail.com>
References: <eadd4a32-a05b-463b-a91f-a5d353c577b2@www.fastmail.com>
 <CAEPJdum2C2RTrFmBunHBF9uUVge90JGmbAH=mJY0MD7e3uduNw@mail.gmail.com>
Date: Fri, 01 Jan 2021 13:30:38 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] Enumerations, Round 2
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Jan 1, 2021, at 12:08 PM, Benjamin Eberlei wrote:
> On Mon, Dec 28, 2020 at 9:22 PM Larry Garfield <larry@garfieldtech.com>
> wrote:
> 
> > Hello, Internalians!
> >
> > After considerable discussion and effort, Ilija and I are ready to offer
> > you round 2 on enumerations.  This is in the spirit of the previous
> > discussion, but based on that discussion a great deal has been reworked.
> > The main change is that Enumeration Cases are now object instances of the
> > Enumeration class rather than their own class.  Most of the other changes
> > are knock-on effects of that.
> >
> > Of particular note:
> >
> > * Cases may not have methods or constants on them.  They're just dumb
> > values.
> > * Enums themselves may have methods, static methods, or constants.
> > * Traits are supported, as long as they don't have properties.
> > * The value() method on scalar enums is now a property.
> >
> > The full RFC is here, and I recommend reading it again in full given how
> > much was updated.
> >
> > https://wiki.php.net/rfc/enumerations
> >
> > The implementation is 98% complete; there's still a few lagging bits in
> > reflection, and some opcache bugs that Ilija is still stomping on.
> >
> > There are a few outstanding questions listed that we would like feedback
> > on.  We're not entirely certain which direction to go with them, for
> > reasons explained in the RFC.  Input on those is especially welcome.
> >
> > Happy New Year.  May it be enumerable.
> >
> 
> I think the reflection part is the weakest of this proposal, in my opinion
> there should not be a ReflectionEnum and ReflectionCase.

I'd agree that Reflection is the place we still have the most open questions.  (The listed attribute open questions are synonyms for reflection questions, in a sense.)  I disagree with removing their reflection classes entirely, though.

> - ReflectionEnum extends ReflectionClass is problematic

Why?  The main alternative is making it its own thing entirely, which seemed redundant.

> - is hasEnum just an alias for hasConstant?

Assuming you mean hasCase(), no.  An enum can have constants now in addition to cases.  So for instance:

enum Foo {
  case Bar;
  const Beep = self::Bar;
}

hasCase('Beep') would return false.  hasConstant('Beep') returns true.

> - Same for getCases() for getConstants().

As above.  Not all constants are cases.  That cases are constants is an implementation convenience.

> - what does getConstant() or ReflectionClassConstant::getValue return for a
> non scalar enum? the instance?

ReflectionEnum::getConstant() would return the case instance object, whether or not it's scalar.

> In my opinion you should embrace the "desugarizing" like constructor
> promotion and just keep everything with the exsiting Reflection structure.

Enums are more than "just" sugar on objects, though.  They're built on objects, but they have limitations that objects don't have, and features objects don't have.  And ideally those will expand in future RFCs.  Having no difference at all between them an objects in reflection even though their functionality is different at a user level seems needlessly confusing and limiting to me.

--Larry Garfield