On Thu, Mar 4, 2021 at 5:26 PM Larry Garfield <la...@garfieldtech.com>
wrote:
> On Thu, Mar 4, 2021, at 7:53 AM, Nikita Popov wrote:
>
> > I've added a section that describes reflection methods. It works exactly
> as
> > you say.
> >
> > There is one interesting case though: How should
> > ReflectionObject::newInstanceWithoutConstructor() work? In the current
> > implementation, it will still evaluate the property defaults, including
> new
> > expressions. This makes sense to me, but I can also see an argument that
> > this method should not evaluate them -- however, in that case I believe
> it
> > should not initialize any properties at all (leave them in
> "uninitialized"
> > state). Populating property default values depending on what kind of
> > expression they contain seems like a no-go to me.
> >
> > @Ben Ramsey: Yes, it's possible to use nested new. Generally, all
> supported
> > constant expressions can be freely combined.
> >
> > Regards,
> > Nikita
>
> Would that then end up allowing enum cases to have an object backing value?
>
> enum Suit {
> case Hearts = new Heart;
> case Spades = new Spade;
> }
>
> Or is there something else that would prevent that? (I know Ilija ran
> into some complications there.)
I believe enums enforce the limitation to strings and integers to allow an
efficient mapping from backing value back to enum. If we added support for
object array keys then we could theoretically support an object backing
value -- but I don't really see why we should, or what that would be useful
for. (Worth noting that this RFC does not introduce objects into
initializer expressions -- the enum RFC does that. This RFC then removes
the enum-only limitation.)
Regards,
Nikita
