Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89247
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.29 cause and error)
To: internals@lists.php.net
References: <CABHuAWzi5n_5k_7QNLQNwYuD+xxWN9OcJsz28ED4OB=MVZuLCQ@mail.gmail.com>
Message-ID: <564A547C.9060504@garfieldtech.com>
Date: Mon, 16 Nov 2015 16:11:08 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <CABHuAWzi5n_5k_7QNLQNwYuD+xxWN9OcJsz28ED4OB=MVZuLCQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Immutable modifier
From: larry@garfieldtech.com (Larry Garfield)

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.

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.

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).

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.

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. :-)

-- 
--Larry Garfield