On Thu, Jun 17, 2021 at 11:14 AM Nicolas Grekas <
nicolas.grekas+...@gmail.com> wrote:
> Le mer. 16 juin 2021 à 13:47, Larry Garfield <la...@garfieldtech.com> a
> écrit :
>
> > On Wed, Jun 16, 2021, at 3:16 AM, Nikita Popov wrote:
> >
> > > > Arguments and attributes are enough to justify this RFC on its own,
> > but is
> > > > there a way we can resolve the static property question? Right now
> > the RFC
> > > > says "these initializers are evaluated lazily the first time a class
> is
> > > > used in a certain way." Can you be more specific about that certain
> > way?
> > > > Is there a certain way that would be minimally disruptive?
> > >
> > >
> > > Well, here is a non-exhaustive description of current behavior:
> > >
> > > * If you access a class constant, only that constant is evaluated.
> > > * If you access a static property, all initializers in the class and
> > > parent classes are evaluated.
> > > * If you instantiate a class, all initializers are evaluated.
> > > * Inheriting from a class or calling a static method doesn't evaluate
> > > anything.
> > >
> > > As you can see, the rules are rather ad-hoc. To the user, it's probably
> > not
> > > obvious why instantiating an object of a class would require evaluating
> > > class constants at that point. The reason is that instantiation
> requires
> > > resolved property defaults, and we happen to evaluate all initializers
> at
> > > once.
> > >
> > > The options where static properties and class constants are concerned
> > are:
> > >
> > > 1. Eagerly evaluate initializers on declaration. This is what I tried
> in
> > an
> > > earlier revision of the RFC, and I don't think that approach works. It
> > > breaks existing code and has various other unpleasant complications.
> > > 2. Precisely specify the current behavior. I don't want to do this
> > either,
> > > because the exact places where evaluation happens are something of an
> > > implementation detail. If in the future we find it convenient to
> separate
> > > evaluation of non-static properties on object instantiation from
> > evaluation
> > > of static properties and class constants (which are not strictly needed
> > at
> > > that point), I'd like to retain the liberty to make such a change.
> > > 3. Do not specify an evaluation order, beyond that evaluation happens
> at
> > > certain uses of the class. Evaluation order may change across PHP
> > versions.
> > > If your code relies on any particular order, your code is broken.
> > >
> > > Unless I'm missing a fourth option here, option 3 is the only one I
> would
> > > be willing to go for at this time.
> >
> > Thanks. To clarify, the concern about evaluation order is only relevant
> > if you are initializing a class whose constructor has some kind of side
> > effect, right? Writing to disk or printing or something like that.
> > Otherwise, at worst you may initialize a few more objects than you expect
> > there should be no behavioral change.
> >
> > Given that constructors that have side effects are arguably broken to
> > begin with (modulo debugging), I'd be comfortable with explicitly saying
> > that the evaluation order is undefined, and nothing is guaranteed except
> > that the value will be there when you first access it.
> >
> > In the future, if function initializers or something like that are added
> > we can revisit that question, though I would be tempted to say the same
> > thing in those cases; if you want to do some kind of DB read in a
> function
> > that is a default value for a property or a parameter, frankly odds are
> > you're already doing something wrong to begin with. But that's a bridge
> we
> > can cross if and when we get to it.
> >
> > Would others be comfortable with that, if it allowed new-initializers for
> > static properties and class constants?
> >
>
> Honestly, I don't know.
>
> Instantiation might fail because of either a throwing constructor or
> because of a throwing autoloader.
>
> Being able to know where to put the try/catch to recover from these might
> be important when writing generic code.
>
> With the current state of the RFC, it's fine. With "undefined evaluation
> time", it might make things fragile without any way to make them resilient
> enough.
>
> We should think twice before going this way IMHO. I'm not sold yet this is
> a compromise we should make.
>
Worth noting that static prop / class constant initializers can already
throw, e.g. if you write something like "const Foo = [] + 1;". Of course,
with constructors this may become more prevalent. Even if we went with
evaluation during class declaration, the result would be pretty awkward, in
that the only way to catch such an exception would be to wrap the whole
class declaration:
try {
class X {
const Foo = [] + 1;
}
} catch (Error) {}
Regards,
Nikita
