[RFC][DISCUSSION] - Immutable classes and properties

Hi,

Discussion is open for following rfc https://wiki.php.net/rfc/immutability

Cheers

Some grammar issues:

"After object is constructor" => should be "After the object's
constructor has run".

" If immutable property contains object, to preserve immutability,
object that is beeing assigned to immutable property must also
immutable." => "If an immutable property contains an object, then in
order to preserve immutability the object being assigned must be of an
immutable class."

The File class/resource example should note that the last line in it
will create a fatal error, as the earlier examples do. It's not clear
that the example is an invalid one.

In a few places, "If immutable property..." should be "If an immutable
property..." There's several places where articles (the, an, etc.) are
missing.

"Notice in above examples removing getters and setting properties to
public is optional. They simply doesn't need to be protected anymore in
fact that immutable class objects are deeply frozen with eceptions on
write." => "Notice in the above examples that removing getters and
setting properties to public are optional. They simply don't need to be
protected given the fact that immutable class objects are frozen on
write." (Several grammar fixes, plus it's a fatal error, not an exception.)

Content issues:

Currently the only "unlocked context" for an object is its constructor.
As discussed previously, that is insufficient. For any non-trivial
object (more than 1-3 internal properties) creating a new one via the
constructor only when incrementally building is prohibitively
difficult. The pattern of with*() methods that spawn new objects via
clone(), a la PSR-7, needs to be supported. That is:

immutable class Money {
// ...

public function add(Money $other) : Money {
$new = clone($this);
$new->amount += $other->amount;
return $new;
}
}

I'm not sure how easily we can denote that sort of case. It's outside
the __clone() function itself, which is what makes it difficult.
Without that, though, such immutable objects are of only limited use.

--Larry Garfield

2016-12-11 12:57 GMT-04:00 Silvio Marijić marijic.silvio@gmail.com:

Hi,

Discussion is open for following rfc https://wiki.php.net/rfc/immutability

Cheers

Hi,

Can you make a pull request? I'd like to comment the patch but it's not
possible to make inline reviews only with a diff uri on github.

Hi,

Discussion is open for following rfc https://wiki.php.net/rfc/immutability

Cheers

-1 from my side for all the things previously mentioned. The
copy-on-write topic must be solved along with the introduction of
immutable classes or we end up with this being implemented and not way
to mutate them in a controlled fashion.

Also -1 on the proposed copy or modify function. Not only does it
seem to allow anyone to mutate the immutable object, it also requires
magic strings of the property names. No usage search, no refactoring, no ...

I still strongly believe that __clone should be made private or
protected for immutable classes to avoid useless cloning. After that
we either stick to cloning as we currently do in our with* methods or
we provide a keyword that changes the behavior of a method.

I also propose to use data or value instead of immutable as the
class modifier keyword. Its shorter and properly as well as fully
communicates what kind of object we are building.

--
Richard "Fleshgrinder" Fussenegger

Hi Silvio,

Silvio Marijić wrote:

Discussion is open for following rfc https://wiki.php.net/rfc/immutability

The restriction that immutable properties may only hold immutable values
seems potentially overzealous. Consider that not all immutable classes
will actually be marked as such. Any code written in, say, PHP 7.2 if it
included this feature, would not be able to make an immutable property
if it pointed to an immutable object made before PHP 7.2 which couldn't
use this feature.

Another consideration is that your existing restrictions (only objects
of immutable classes and resources) are not restrictive enough to
achieve the desired end of enforcing deep immutability. Arrays can
contain object values, as well as array values which might themselves
contain values that are objects. They also can contain references. In
order to enforce that immutable properties do not point to anything
mutable, you would have to search any given array for mutable values,
including sub-arrays. You would need to make sure you check for recusion
here, lest assigning to an immutable property potentially crash the
interpreter. This could be a significant runtime cost, it's at least an
O(n) operation.

I think that, realistically, trying to enforce immutability of values in
an immutable class is not worth it, and makes the feature less useful.
Consider that some popular applications of immutability ultimately
contain a reference to something mutable: PSR-7's immutable HTTP message
objects point to mutable streams, and Docker's immutable containers
point to mutable volumes.

Thanks.

--
Andrea Faulds
https://ajf.me/

Hi!

Discussion is open for following rfc https://wiki.php.net/rfc/immutability

The RFC says:

Safe for concurrency.

I'm not sure - what concurrency are you talking about?

Value objects, DTO's etc. can be easily created.

Value objects can be easily created right now if you follow generic best
practices - private properties and no setters, here you go with value
object.

Properties can be public which removes need for getters without
allowing state modification.

Not sure why it is a good thing to have public properties? Also, not
sure how you are going to resolve references to such properties.

--
Stas Malyshev
smalyshev@gmail.com

This have occurred to me also, I wanted to separate that into two RFC's,
but then how we deal with RFC's that depend on each other?

2016-12-12 1:03 GMT+01:00 Larry Garfield larry@garfieldtech.com:

Assuming this was intended for the list...

Currently the only "unlocked context" for an object is its
constructor. As discussed previously, that is insufficient. For any
non-trivial object (more than 1-3 internal properties) creating a new
one via the constructor only when incrementally building is
prohibitively difficult. The pattern of with*() methods that spawn
new objects via clone(), a la PSR-7, needs to be supported. That is:

immutable class Money {
// ...

public function add(Money $other) : Money {
$new = clone($this);
$new->amount += $other->amount;
return $new;
}
}

I'm not sure how easily we can denote that sort of case. It's outside
the __clone() function itself, which is what makes it difficult.
Without that, though, such immutable objects are of only limited use.

As you said, it has been already been discussed that a method to build
new altered object from an existing one could be improved. Different
options were proposed but maybe it's better to start small to get this
first part right and add this in another rfc ? having everything at the
same time might makes the rfc more difficult to be accepted

On the contrary, an RFC that doesn't fully solve the issue at hand and
leaves major gaps in place is a poor RFC, and I would expect to be
justifiably voted down.

--Larry Garfield

--

--
Silvio Marijić
Software Engineer
2e Systems