On Mon, Sep 6, 2021 at 5:28 PM Nikita Popov <nikita....@gmail.com> wrote:
> What do people think about adding such an alias? Is this worthwhile? > What if `DynamicObject` becomes an interface instead of an alias? In the future `stdClass` could be deprecated and replaced by anonymous classes using the `DynamicObject` interface to prevent manual initialization. I feel like renaming (this seems to be the end-goal) will not solve some of the problems that `stdClass` brings to php. Hamza Ahmad brought the interface up in the other thread: https://externals.io/message/115800#115806 . ```php // core php interface DynamicObject { /* ... /*} // in case of removal, legacy support could be kept as class stdClass implements DynamicObject { use DynamicObjectTrait; // perhaps also core php? } // a library wants a DynamicObject for whatever reason? final class MyCustomDataObject implements DynamicObject { public function __get(string $name) : mixed { // as a developer I now have full control over where // this data comes from and is stored internally } /* ... */ } ``` To me it feels like making this an interface gives PHP more flexibility in dealing with this in the future. One intermediate step could be to turn `stdClass` into an interface that extends `DynamicObject`. 8.2 could deprecate manual instantiation of `stdClass`, meaning that in 9.0 it could be removed as class and turned into an interface, reducing the need to update code relying on the `stdClass` types. `get_class` would still return `stdClass` in 8.x and thus not break when using a `DynamicObject`.
