On Sun, Sep 23, 2018 at 10:08 PM Rowan Collins <rowan.coll...@gmail.com> wrote:
> On 23/09/2018 19:41, Claude Pache wrote: > >> 3) Object properties may be type hinted and the class author has until > the end > >> of the constructor to make sure they're fulfilled, otherwise TypeError > on the > >> spot (what I'm proposing). > > Just to be sure you don’t miss the herd that this elephant is concealing: > > > > In addition, you *must* forbid unset() on those properties... > > > We "must" forbid this IF we aim to guarantee that the object never has > uninitialised properties; but the current consensus is that we can't > make such a guarantee without changing a lot of other parts of the > language. > > There are strong feelings that unset should be available for use in > lazy-initialisation hacks, so this is likely to remain one of the > back-doors which will let elephants in, unless and until someone comes > up with a replacement for that hack. > There might be a compromise here, which is to only perform a ctor initialization check and forbid explicit unset()s if the class does not use property accessors (i.e. does not define __get). This allows the lazy initialization pattern but is stricter for everything else. (Possibly __get in subclasses would also count.) Nikita
