On Sun, 23 Sep 2018 at 22:48, Nikita Popov <nikita....@gmail.com> wrote:

>
> 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.)
>

Hm, that's an interesting suggestion, but I think it might get a bit
complicated and confusing.

There's also the paradoxical fact that you can implement __get() to make
your classes *stricter*: public function __get($prop) { throw new
\LogicException("Attempt to access non-existent property $prop"); }

I think I'd prefer to leave the unset() behaviour in, and then:
a) come up with a better mechanism for lazy-initialisation
and b) come up with a way for classes to opt out of having *any* dynamic
property manipulation (no unset, no reads or writes to undeclared
properties)

I might start a thread to bikeshed an appropriate mechanism for (b) because
it's something I've wanted for a long time.

Regards,
-- 
Rowan Collins
[IMSoP]

Reply via email to