On 08/09/2021 09:45, Mike Schinkel wrote:
So I am trying to get around what this would actually mean in practice, and
what the ramifications would be.
The proposal is that the new name is an "alias" - the same class, but
with two names. So the following would all create exactly the same object:
$obj = new stdClass;
$obj = new DynamicObject;
$obj = (object)[];
The following would be true for all of them:
assert( $obj instanceOf stdClass );
assert( $obj instanceOf DynamicObject );
There are some places that have to return some "real" name for the
class, like get_class($obj). The current proposal is that "stdClass" be
kept as the real name, at least initially, so you would see this:
$obj = new DynamicObject;
echo get_class($obj); // stdClass
So while trying to get my head around the ramifications I prepared
this bit of introspection, which is still missing some applicable
tests I am sure:
https://3v4l.org/MDlOn#v8.0.10
You can get a better idea of what's being proposed using the
class_alias() function, which lets you create an alias for a
user-defined class: https://3v4l.org/a4EI0#v8.0.10
Is it just a special-cases that will cause as much confusion for developers
trying to understand why there are too names for the same thing as it will help
those who will better understand the new name
That is certainly a risk, and a factor in favour of having some plan to
retire the old name, even if only after a long overlap.
or is it more fully addressing the use-case for why people use dynamic
objects?
The thread comes from a comment I made in Nikita's discussion about
deprecating dynamic properties on normal objects. There was no grand
vision behind it, just a long-standing dislike of the name "stdClass",
and a concern that documenting "extends stdClass" as a way to enable
dynamic properties on a custom class would make the confusion worse.
So what are the use-cases where dynamic objects still make sense, and just as
importantly what about those use-cases is still suboptimal besides just the
class name?
To be honest, I think most uses of stdClass would be better served by
anonymous classes, and would have been written that way if the feature
had existed for longer. The one thing missing from anonymous classes
right now is an elegant way to capture data from outer scope when you
create them.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php