Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81442
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.171 as permitted sender)
Message-ID: <54CBC804.7050706@gmail.com>
Date: Fri, 30 Jan 2015 18:05:56 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAEbg-4YrBumSmCmvTbgVQTS=U2dm3gLzO6im69qQp6brxm=RMg@mail.gmail.com>
In-Reply-To: <CAEbg-4YrBumSmCmvTbgVQTS=U2dm3gLzO6im69qQp6brxm=RMg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Immutable variables and objects
From: rowan.collins@gmail.com (Rowan Collins)

On 30/01/2015 13:07, Alexander Lisachenko wrote:
> What is wrong here? Emulated immutability. All methods will create a
> separate instance of request, so
> $baseRequest->withUri()->withMethod()->withHeader()->withBody() will create
> total 5 object instances. It's a memory overhead and time consumption for
> each method call.

Like Andrea, I don't see how immutable variables/objects solve this 
problem. The overhead is not from emulating the immutability, it is a 
consequence of the design pattern choosing immutability. In fact, from 
the code shown, there is no way to know that immutability is in any way 
relevant, since the definition of withUri() could be a mutator which 
ends "return $this", a pattern I've frequently used to create such 
"fluent" interfaces. Copy-on-write doesn't help, either, since all 5 
calls are writes, so will still make 5 copies.

> What I want to discuss is true immutability flag for variables and
> parameters. There are a lot of languages that use "final" or "const"
> keywords to prevent modification of variables.

On the concrete suggestion, though, I do think there are possible 
advantages to this. I've long felt the confusion people have over 
pass-by-value for primitives, pass-by-value-which-is-actually-a-pointer 
for objects, and pass-by-reference for a variable which might or might 
not be an object pointer, is a failure not of the programmer but of the 
programming language. In a blog post about it a few years ago [1], I 
suggested that deep immutability (along with deep cloning) could provide 
a better framework than by-value vs by-reference in modern OO languages.

This is rather different from defining a *type* that is immutable, since 
it implies temporary immutability of a particular instance; but it seems 
to be what at least some of your examples are hinting at.

The problem is that deep cloning and deep immutability are non-trivial; 
PHP notably doesn't support deep cloning of objects, requiring each 
class to define what to do with any non-primitive members, since some 
may represent resources which can't be meaningfully cloned just by 
copying data in memory.

In the same way, in order to make an instance deeply immutable, you need 
to nail down the details of which actions are actually allowed while 
it's in that state, and that gets complicated:

- Directly assigning to a public property is clearly invalid, as is 
calling a method on that property which mutates it.
- If the property is itself an object, assigning it to a temporary 
variable must retain the immutability - that is, we don't want 
"$foo->bar->setValue(42);" to behave differently from "$x = $foo->bar; 
$x->setValue(42);"
- Calling a method which internally performs such an action is also 
invalid (like the setValue() in the example above). This could be 
achieved by executing the function but marking $this as immutable, but 
that means that the method may have other effects up to the point where 
the violation occurs, so it would be preferable to somehow invalidate 
the method call.
- For objects which represent proxies for external resources, there may 
be methods which mutate that external state, and properties which exist 
only as virtual getters. So calling $db->insertRow(...) should probably 
be invalid, since it changes the value of $db->lastInsertedId.

I think the only way to do it would be for every method to be invalid 
unless it is explicitly marked as "immutable-safe", e.g.

class Foo {
private $delegatedObject;
public function __construct() { $this->delegatedObject = new 
SomethingElse; }
immutable public function getValue() { return 
$this->delegatedObject->getX(); }
public function setValue($newValue) { echo "Setting!"; 
$this->delegatedObject->setX($newValue); }
}
const $foo = new Foo;
echo $foo->getValue();
$foo->setValue(42); // Instantly fails without echoing "Setting!", but 
method is illegal in immutable context

Copy-on-write, at the user object level, requires both this *and* deep 
cloning:

$bar = clone-on-write $foo;
$bar->setValue(42); // Needs to implicitly clone $foo before calling 
setValue(), but must also clone $delegatedObject for that to be meaningful

So class Foo needs an implementation of __clone() as well before any of 
this can be used, and if it is missing, the resulting behaviour may be 
rather non-obvious.

As ever, the devil's in the detail. The only language I know of that's 
meaningfully tackled this is Rust, with its concepts of "boxes" and 
"lending", although I'm hazy on the details.

[1]: http://rwec.co.uk/blog/2010/08/object-references-are-confusing/

Regards,

-- 
Rowan Collins
[IMSoP]