Hi Chris!
On 9/3/2016 5:00 PM, Chris Riley wrote:
- Properties can be declared immutable. Immutable properties may only be
changed under two circumstances: a) In the objects constructor b) If they
are null (This enables setter injection if required)
The constraint b) would make the object mutable and defeat the purpose
of the immutable modifier since any property could change at any time if
it was NULL at the beginning. Requiring syncing in concurrent environments.
On 9/3/2016 5:00 PM, Chris Riley wrote:
- Arrays assigned to immutable properties would not be possible to change
Array support would definitely be very nice. I mean, we have constant
arrays already, hence, it is possible.
On 9/3/2016 5:00 PM, Chris Riley wrote:
- Objects assigned to immutable properties would be possible to change,
so
long as the same object remained assigned to the property.
This would once more lead to mutability and the constraint of
immutability would be violated.
On 9/3/2016 5:00 PM, Chris Riley wrote:
From a developer adoption point of view, I think these two points are
important to making immutable classes generally useful. Without 1, it
will
be a nuisance to use 3rd party libraries esp those which retain
compatibility for PHP < 7.2. Without 2 you block the ability to use
setter
injection, which I personally would be in favour of if it meant that devs
stopped using it - it wouldn't - they would simply not use immutable
classes, loosing the benefits thereof.
The adoption of the feature will be halted until 7.2 is widely available
in bigger projects. That is most certainly right. However, we should aim
for the best, most useful, and future proof solution and not towards the
one that's adopted very fast but lacks some important constraints.
Having truly immutable objects is required in concurrent scenarios and
such scenarios are in the future for PHP and not in the past.
Regarding setter injection: I do not see the need for it at all in the
context of immutable objects. In the end we are talking about value
objects here and they should not have any optional dependencies. Maybe
you could come up with a use case to illustrate the need?
On 9/3/2016 5:00 PM, Chris Riley wrote:
Dealing with the clone issue some of my ideas since then were:
- Seal/Unseal (As per Larry's suggestion)
- Parameters to __clone; in this instance the clone method would be
allowed
to change properties of the object as well as the constructor. This feels
like it may breach the principal of least surprise as cloning an object
no
longer guarantees an exact copy.
- A new magic method __mutate($property, $newvalue) called instead of a
fatal error when a property is changed. This probably lays too many traps
for developers for it to be a good idea.
- Implicitly returning a new object whenever a property is changed.
Similar
reservations to the above.
- A new magic method __with($newInstance, $args) and a keyword with that
is
used in place of clone eg $x = $y with ($arg1, $arg2); in this instance,
__with receives a clone of $y (after calling __clone) and an array
[$arg1,
$arg2] the with magic method is allowed to mutate $newInstance and must
return it. This is currently my favoured solution
How does one know which property is to be mutated in the __with method?
You should also not underestimate the performance hit and the branching
since you only want to change the properties that changed based on the
data from the passed array.
I have a third proposal after giving this some more thought. Inspired by
Rust's approach to mark mutation explicitly.
final immutable class ValueObject {
public $value;
public mutator [function] withValue($clone, $value): static {
$clone->value = $value;
}
}
