Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89248
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain rochette.cc designates 195.154.14.121 as permitted sender)
To: Larry Garfield <larry@garfieldtech.com>, internals@lists.php.net
References: <CABHuAWzi5n_5k_7QNLQNwYuD+xxWN9OcJsz28ED4OB=MVZuLCQ@mail.gmail.com>
 <564A547C.9060504@garfieldtech.com>
Message-ID: <564A629C.9040709@rochette.cc>
Date: Tue, 17 Nov 2015 00:11:24 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101
 Thunderbird/44.0a2
MIME-Version: 1.0
In-Reply-To: <564A547C.9060504@garfieldtech.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Immutable modifier
From: mathieu@rochette.cc (Mathieu Rochette)



On 11/16/2015 11:11 PM, Larry Garfield wrote:
> On 11/16/15 3:15 AM, Chris Riley wrote:
>> Hi,
>>
>> There has been a lot of interest recently (eg psr-7) in immutable 
>> data. I'm
>> considering putting an RFC together to add language support for 
>> immutables:
>>
>> immutable class Foo {
>> public $bar;
>> public function __construct($bar) {
>> $this->bar = $bar;
>> }
>> }
>>
>> Immutable on a class declaration makes all (maybe only public?) 
>> properties
>> of the class immutable after construct; assigning to a property would
>> result in a Fatal error.
>>
>> class Foo {
>> public $bar;
>> immutable public $baz;
>> }
>>
>> Immutable on a property makes the property immutable once it takes on a
>> none null value. Attempts to modify the property after this results in a
>> fatal error.
>>
>> Any thoughts?
>> ~C
>
> As a firm believer in the value of immutable data structures, I don't 
> believe such a simple approach would be useful and would likely be 
> counter-productive.
agreed
>
> The trick is there are 2 cases for immutability: An immutable service 
> object, and an immutable data object.
>
> A service object should be immutable once it's setup.  However, that 
> setup *may*, in some cases, involve setter injection.  That's inferior 
> or constructor injection but that is not always feasible. In practice, 
> I'm not sure we need new syntax here at all.
I'm curious here, why is construction not always enough ? do you have a 
use case in mind ?
>
> For data objects, this is where it gets interesting.  Data objects 
> *do* need to be modifiable for a given context... for that context. 
> Immutable data objects are, largely, useless and in my experience 
> harmful unless they have a ->giveNewVersionWithThisOneChange() 
> method.  In PSR-7, that's the with*() methods.  DateTimeImmutable has 
> the same methods as DateTime, but they return new instances rather 
> than modifying the invoked object (despite their confusing names, 
> which are like that for historical reasons).
How does that makes them mutable in a "given context" ? the with*() can 
always create a new object with everything in the constructor, am I 
missing something ?
>
> My ideal would be to revive the property RFC and leverage per-property 
> access control separately for read and write to create 
> externally-immutable objects.  That would allow for with*() methods to 
> be implemented as appropriate for a given object.
are you talking about this one ? 
https://wiki.php.net/rfc/readonly_properties
>
> The problem with a simple keyword approach is that "modifier" methods 
> often should not, and in the case of PSR-7 cannot, correspond to 
> simple get/set mapping to an object property.  (See withAddedHeader(), 
> withoutHeader(), etc.)  Some level of flexibility needs to be given to 
> the implementer to create an effectively-immutable object that is more 
> than just a bare struct that's hard to work with.  If there were some 
> way to flag for the compiler that "This object is supposed to be 
> effectively-immutable, please check and make sure I didn't screw that 
> up", that would be lovely but sounds hard. :-)
>


-- 
Mathieu Rochette