Creating a new DynamicObject class which is the preferred alias for stdClass sounds logical but I too share the consern around making it the default anytime soon. Too much code depends on an expected type of stdClass presently which would likely make future upgrades more difficult for no functional gain, beyond some added clarify.
With functions such as json_decode() still returning stdClass by default, this is the main bug bare I can forsee where we commonly strict type passing the decoded value throuh to another method or type. Would be nice if in the future you could specify a class to populate instead of stdClass - just a thought. I too share the same view on deprecation notices being enfored and although this would probably warrent its own thread, perhaps there benefit in resolving this in itself under another RFC where a new php.ini directive, or method call could be used to silence certain specified deprecation warnings for those that are aware and understand the changes required in the future so can knowingly make a decision to mute them. On Mon, 6 Sep 2021, 18:50 Björn Larsson via internals, < internals@lists.php.net> wrote: > Den 2021-09-06 kl. 18:22, skrev Christian Schneider: > > Am 06.09.2021 um 18:08 schrieb Benjamin Morel <benjamin.mo...@gmail.com > >: > >> Yes, please! A future where dynamic properties are only allowed on > >> DynamicObject is bright. > > > > I have nothing against a DynamicObject alias for people who like to be > more explicit in their code... > > > > Totally agree here! > > >> I would even deprecate the stdClass alias straight away, so that the > whole > >> thing can be gone in PHP 9. > > > > ... but I'd prefer retaining a backward compatible version for library > code, at least for a while and preferably without warnings :-) > > > > - Chris > > > Couldn't agree more on the statement "without warnings"! > > I mean if one have code that is in production, is running perfect and > one wants to upgrade to the newest and fanciest PHP version and the > logs are flooded with warnings for a deprecation with zero impact on > functionality. What do one do? Maybe just turn of the warnings for > that code section / library ;-) > > r//Björn L > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
