Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93080
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 207.46.100.127 as permitted sender)
To: Larry Garfield <larry@garfieldtech.com>, <internals@lists.php.net>
References: <5723F2AE.2020806@garfieldtech.com>
 <f6a2370f-0468-6279-3981-82ed2eec4b90@gmail.com>
 <572529F2.9070606@garfieldtech.com>
 <8e4ed849-f504-fe80-3c5f-e4ea114e99fa@gmail.com>
 <6e3f41ce-4dd5-cd29-a063-fdc9c9c920b8@gmail.com>
 <830b1059-9a9e-b7e1-e338-29d562588e2f@gmail.com>
 <d0bdd623-7374-f081-0227-41613a1266d1@gmail.com>
 <57265D57.1040301@garfieldtech.com>
Message-ID: <7589bb52-8f78-576d-2a79-e8655f14865e@zend.com>
Date: Thu, 5 May 2016 09:47:38 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <57265D57.1040301@garfieldtech.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2016 06:47:51.6264 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1783
Subject: Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal
From: dmitry@zend.com (Dmitry Stogov)



On 05/01/2016 10:47 PM, Larry Garfield wrote:
> On 04/30/2016 06:21 PM, Rowan Collins wrote:
>> On 30/04/2016 23:45, Stanislav Malyshev wrote:
>>> Oh, of course you can have methods, but then it is strange conceptually
>>> - you have a normal class, which some other part of the language just
>>> uses for something else that classes are not routinely used for. I.e.,
>>> does it call a constructor? When? With which arguments? What if it
>>> fails? What if I just create an object of this class - would it be the
>>> same as annotation object?
>>
>> Hm... I was going to say "well, PDO does this if you use 
>> PDOStatement::fetchObject"; but then I remembered that the 
>> integration with the object there IS a bit weird - it injects raw 
>> properties, and *then* calls the constructor.
>>
>> So, I'm not sure there's a limitation in terms of the object being 
>> data-only per se, but there are certainly oddities to be dealt with 
>> in terms of construction. And as you mentioned, mutability leads to 
>> another set of oddities - are the mutations stored for next time you 
>> request that annotation, or is the object recreated on each access?
>>
>> Regards,
>
> It would never occur to me to not have it regenerated on each access.  
> If I want to cache it I will do so myself, thanks. :-)
>
> However, that is not an issue created by using a defined structure for 
> the annotation result.  The RFC currently says it returns an 
> associative array, aka anonymous struct.  Those are always highly mutable.

The RFC proposes only Reflection*::getAttributres() that returns by value.
You may modify the returned copy, but the original attributes are immutable.

Thanks. Dmitry.

> A classed object is as mutable as its design allows it to be.  To wit:
>
> <<__Annotation>>
> class Definition {
>   protected $foo;
>   protected $bar;
>   public function getFoo() {}
>   public function getBar() {}
> }
>
> <<Definition(foo => 1, bar => 2)>>
> class Meep {}
>
> The resulting annotation object would be an instance of Definition, 
> which is for practical purposes immutable.  If it were returned as an 
> array ['foo' => 1, 'bar' => 2], that would obviously be mutable.
>
> Whether Definition should have mutator methods on it then becomes the 
> implementer's decision, which is probably for the best.
>
> --Larry Garfield
>