Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92187
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.27 cause and error)
To: internals@lists.php.net
References: <CABdc3WqHbH6EmAZ3ZFW2spMmEmm5-yJy6rtUznNHkocVDiP8uA@mail.gmail.com>
 <CADyq6s+iTVCT8KQ13EYs4CV2W13WP+aBihsq5xHyM-hZ=jefag@mail.gmail.com>
 <CABdc3WqVGnj=WUUGJKnTfM9QVtAzshBv6ivTg2i3sA8ehdnBXw@mail.gmail.com>
 <CADyq6sJavebrYVBdYXHt6Q3imFZCDDdPu=0OQRmwJo4CLh+oww@mail.gmail.com>
Message-ID: <570B2F3B.7040609@garfieldtech.com>
Date: Sun, 10 Apr 2016 23:59:39 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <CADyq6sJavebrYVBdYXHt6Q3imFZCDDdPu=0OQRmwJo4CLh+oww@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Final properties
From: larry@garfieldtech.com (Larry Garfield)

On 04/05/2016 05:13 AM, Marco Pivetta wrote:
>> Ad. 2. `final` means class variable (like static) or class instance
>> property can not change their reference, it is impossible to replace zval
>> in such property, in my opinion `immutable` is object behavior when using
>> some methods you receive newly created (cloned) object which is changed
>> exactly like `DateTimeImmutable`
>> http://php.net/manual/en/datetimeimmutable.add.php
>>
> I am aware of what `final` means in other languages, it just seems that
> everyone then needs to translate back and forth from `final` to
> `immutable`. In addition to that, `final` has different meaning in
> inheritance (re-used keyword), so this adds to the confusion for people
> unfamiliar with the feature.

There's an important point here that should not be missed.  If these 
values are "write once then locked', which I can definitely see as 
useful, we need to have another shot at modifying them from __clone().  
If not, they are effectively useless for implementing objects in the 
style of DateTimeImmutable or the PSR-7 Request/Response objects.  
Locking after __construct or __clone (as appropriate) is done is fine, 
but if we can't clone-and-modify then I would pretty much never find 
value in this feature (no pun intended).

I agree that final seems like a potentially confusing keyword, as every 
other use of final (AFAIK) means "subclass cannot change this", but 
that's not at all the meaning here.

Another question, which unfortunately runs straight into the previous 
Properties RFC: If a public property is write-once, with the intent 
being that it's set from the constructor and then cannot be overridden 
but is publicly exposed... shouldn't an interface be able to declare it 
as well?  It makes public properties safe to use in some cases, but you 
can't rely on that safely without an interface.

(Which leads to "can interfaces define properties", which leads right 
back to "well what can you do with them", which leads back to the 
Properties RFC. Which I still want to see happen at some point if at all 
possible, as it would also subsume this question quite nicely.)

--Larry Garfield