> > Reflection is not slow: it is only slow if you instantiate it continuously.
Even when pre-instantiating the ReflectionProperty objects, it's still 2.5x slower than a closure-based approach, according to my benchmarks (linked below), so if possible, I'd like to avoid using Reflection for this sole reason. It's possible and someone even worked on an implementation at some point ( > https://github.com/php/php-src/pull/1530), but I don't believe this ever > proceeded to the RFC stage. (I'm rather doubtful about introducing > something like this, due to the quite significant increase in conceptual > language complexity for little benefit. I definitely have no plans to > pursue such a feature myself.) Thanks for the pointer! I can see from this thread that another PR has been merged just over a month ago, to implement a ZEND_ARRAY_KEY_EXISTS opcode to overcome the performance penalty of array_key_exists(): https://github.com/php/php-src/pull/3360 Couldn't we broaden the scope of this opcode, or add a new one, to support object properties? Pardon my ignorance, but what is exactly increasing the language complexity? Do you mean the addition of a language construct to the parser? The distinction you need has nothing to do with nulls, it has to do with > the very specific case of "this property currently violates its contract > and I want to treat that as something other than an error". I personally > still think that unset() should raise an error for typed properties, but > apparently there are cunning hacks that it makes possible; as such, 99% of > PHP developers should never need to detect this state. You're right, in most of the cases properties SHOULD be set by the constructor. I do find the current behaviour interesting, however, from a data mapper point of view: you might want to retrieve a partial object from the database, and get an Error if you accidentally access an uninitialized property, as opposed to the pre-typed properties era, where you would get null and the "error" would be silenced. It therefore makes more sense to me to have this as a specific API relating > to typed properties; if it can be done faster outside the reflection class, > it could be in the form of a new function like > property_is_initialized($object, $propertyName); this would be an extension > of property_exists, that handles the edge case of "declared with a type and > then explicitly unset". I don't mind if, instead of another language construct, it is a function; to avoid the same performance penalty as array_key_exists() however, this function should have a companion opcode (just like ZEND_ARRAY_KEY_EXISTS). Would that solve what you call increasing language complexity, Nikita? Ben On Wed, 6 Feb 2019 at 15:09, Rowan Collins <rowan.coll...@gmail.com> wrote: > On 6 February 2019 13:46:32 GMT+00:00, Rowan Collins < > rowan.coll...@gmail.com> wrote: > >it could be in the form of a new function like > >property_is_initialized($object, $propertyName); this would be an > >extension > >of property_exists, that handles the edge case of "declared with a type > >and > >then explicitly unset". > > PS: I realise that it's also possible to accidentally leave a property in > this state with a badly written constructor. I am drafting a proposal to > make this much less likely, and contend that it should not be something > users should be detecting, other than catching the resulting error. > > Regards, > > -- > Rowan Collins > [IMSoP] >
