Hey Marco Pivetta,
> > What are your thoughts on allowing the `(object)` cast in initializer types
> > where `new` was already allowed, but only when followed by an array literal
> > node. (e.g. continue to forbid `(object)SOME_CONSTANT`) (see
> > https://wiki.php.net/rfc/new_in_initializers)
> > ...
> > Reasons:
> > - The ability to construct empty stdClass instances but not non-empty ones
> > is something users would find surprising,
> > and a lack of support for `(object)[]` be even more inconsistent if
> > factory methods were allowed in the future.
> > - stdClass is useful for some developers, e.g. in unit tests, when using
> > libraries requiring it for parameters,
> > when you need to ensure data is encoded as a JSON `{}` rather than `[]`,
> > etc.
> > - It would help developers write a clearer api contract for methods,
> > e.g. `function setData(stdClass $default = (object)['key' => 'value'])`
> > is clearer than `function setData(?stdClass $default = null) { $default
> > ??= (object)['key' => 'value']; `
> > - stdClass may be the only efficient built-in way to represent objects with
> > arbitrary names if RFCs such as https://externals.io/message/115800 passed
> passed
>
> Right now, there's even an interest in getting rid (or deprecating) dynamic
> properties on objects: why push the complete opposite ways?
>
> What is the actual value of using an stdClass instance instead of an
> `array<string, mixed>` (already supported)?
My original message had a section with reasons why an end user might want that.
There's a push for getting rid of (or deprecating) dynamic properties on
**objects that are not stdClass (or subclasses)**
Not a push for getting rid of stdClass. Way too many things use stdClass to get
rid of stdClass.
(whether or not stdClass gets aliased or even renamed to DynamicObject).
```
php > var_dump(json_decode('{}'));
object(stdClass)#1 (0) {
}
```
Thanks,
Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
