On 08/09/2021 11:08, Nicolas Grekas wrote:
I'm reading the discussion about the side of the alias. Can't we solve these concerns by making DynamicObject extend stdClass instead of aliasing? That wouldn't allow an stdClass object to get through the DynamicObject typehint, but that shouldn't be an issue since no such code has yet been written, isn't it?
I've been pondering inheritance options, but I don't think they really help - whichever approach we use, one of these assertions will be false:
assert( new DynamicObject instanceof stdClass ); // false if stdClass is a sub-class of DynamicObject assert( new stdClass instanceof DynamicObject ); // false if DynamicObject is a sub-class of stdClass assert( get_class(new stdClass) === 'stdClass' ); // false if stdClass is an alias of DynamicObject assert( get_class(new DynamicObject) === 'DynamicObject' ); // false if DynamicObject is an alias of stdClass
My guess would be that the name reported by get_class etc would mainly be used in tests and debugging, whereas instanceOf checks (and type constraints) will be used in actual "business logic" code paths. Existing code will expect "instanceOf stdClass" to work, and new code will expect "instanceOf DynamicObject" to work, so an alias (in either direction) seems the better compromise.
Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
