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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
