Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116162
To: internals@lists.php.net
References: <DM5PR17MB14811B9276E2BC5ADFA347D2F9A59@DM5PR17MB1481.namprd17.prod.outlook.com>
Message-ID: <b5b93117-3085-3369-ea2a-19f8d13f6c23@gmail.com>
Date: Sat, 25 Sep 2021 17:59:01 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <DM5PR17MB14811B9276E2BC5ADFA347D2F9A59@DM5PR17MB1481.namprd17.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Allowing `(object)['key' => 'value']` in initializers?
From: rowan.collins@gmail.com (Rowan Tommins)

On 25/09/2021 16:45, tyson andre wrote:
> What are your thoughts on allowing the `(object)` cast in initializer types where `new` was already allowed


I'm not strongly opposed to this, but am not convinced it's a big 
improvement.

Firstly, as with everything involving stdClass, I would be more 
interested in a) improving the initialization of anonymous objects, and 
b) allowing those in initialisers (the RFC currently forbids them, but 
doesn't say why, so I'm not sure if it's an implementation decision or a 
philosophical one).

Secondly, if you have enough knowledge of the structure to provide an 
inline default, then you probably have enough to be worth defining a 
named class, even if that class then implements __set() to allow 
additional ad hoc properties. That class can then have its own defaults, 
so that your example becomes `function setData(Data $values = new Data())`

Regards,

-- 
Rowan Tommins
[IMSoP]