Re: Allowing `(object)['key' => 'value']` in initializers?

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