Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89256
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.42 as permitted sender)
MIME-Version: 1.0
References: <CABHuAWzi5n_5k_7QNLQNwYuD+xxWN9OcJsz28ED4OB=MVZuLCQ@mail.gmail.com>
 <E6.27.34372.9AB8A465@pb1.pair.com>
In-Reply-To: <E6.27.34372.9AB8A465@pb1.pair.com>
Date: Tue, 17 Nov 2015 07:18:40 +0000
Message-ID: <CABHuAWxad3SLK5=DSxo_Jq5rhm3Q4o0GEBVgYiudd4kc-Da7SQ@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=001a1145bd105e4a260524b756b8
Subject: Re: [PHP-DEV] Immutable modifier
From: t.carnage@gmail.com (Chris Riley)

--001a1145bd105e4a260524b756b8
Content-Type: text/plain; charset=UTF-8

On Tue, 17 Nov 2015, 02:07 Andrea Faulds <ajf@ajf.me> wrote:

Hi,

Chris Riley wrote:
>
> 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:
>

I wonder if immutable classes are really the right way to go. Immutable
reference types with manual copying are somewhat alien to PHP: instead,
the language has used copy-on-write mutable value types for arrays and
strings, and prior to PHP 5, objects.

Copy-on-write value types have all the benefits immutable types do. They
can't be mutated at a distance unless you make a reference to them,
trees made of them can be compared for equality with just ===, etc.

But they also have benefits that immutable types lack. They're easier to
work with, because you can directly mutate them like everyone's used to
doing: no messing around with withFooBar() and withoutFooBar(), you just
set foobar or remove it directly. And PHP handles the duplication of
objects for you implicitly, so there's far less code to write.

Unfortunately, PHP 5 got rid of PHP 4's value type objects and replaced
them with reference type objects. But we could always introduce a way to
get value type objects again. How about a `struct` keyword? It would be
equivalent to `class`, but produce a value type rather than a reference
type.

Any thoughts?

Thanks.
--
Andrea Faulds
http:// <http://ajf.me/>ajf.me/ <http://ajf.me/>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:// <http://www.php.net/unsub.php>www.php.net
<http://www.php.net/unsub.php>/ <http://www.php.net/unsub.php>unsub.php
<http://www.php.net/unsub.php>


My main motivation for this was for event objects when doing event sourcing
- they are by definition unchangeable after creation. That said,
considering the wider use case there does seem to be a need to emulate the
with* functions.

One option would be to hide the messy constructor call within user defined
methods, but that would add a lot of boilerplate - something I was wanting
to reduce not increase.

I can't think of a clean easy way to add with* functionality at a language
level without even more magic (parameter skipping?)

As for setter injection - my initial proposal would support that - a
property declared immutable allows itself to be set - once.

If someone can give my wiki account rfc karma I can write this up so far
too help focus discussion.

~C

--001a1145bd105e4a260524b756b8--