Hi Silvio,

Look into my talk about final properties https://marc.info/?
t=145979255800003&r=1&w=2 maybe there would be something usefull.
There is also talk about mutable and immutable properties and other class
modifiers also about var and val.
I'm not sure that it should be class midifier rather than proprty modifier
keyword.

regards,

Michał Brzuchalski

2016-08-08 12:31 GMT+02:00 Silvio Marijić marijic.silvio@gmail.com:

Hi,

I would need your help with one idea. I'm working on one RFC that I'm would
like to submit. Idea is that after you initialize object eg. after
constructor returns, object would be locked, and you wouldn't be able to
change properties on that object anymore. It would like this:

<?php

immutable class Email {

 public $email;
 public function __construct($email){
     $this->email = $email;
 }

}
$email = new Email("example@email.com");

After instance of class is created, object is "frozen" so call like this

$email->email = "new@email.com";

Would result in error.

I have already implementation up to certain degree, but I need one advice
from more experienced developers. Where is the place where I could put
logic to lock object after the constructor has finished? Maybe in zend vm
on ZEND_NEW token?

Some constraints are needed:

1. Child class that extends immutable class must be defined as immutable
   also.
2. If property on immutable class contains object, it must be instance
   of immutable class.
3. You can not have immutability per property, it either whole class or
   none.

Thank you all in advance.

--
Silvio Marijić
Software Engineer
2e Systems

--
pozdrawiam

Michał Brzuchalski

I see Reflection is still todo; should there be a similar escape hatch to ReflectionMethod::setAccessible()?

This would allow things like: https://gist.github.com/fredemmott/01ad55c0c03c8d7ba62bbd6e9fb23686 https://gist.github.com/fredemmott/01ad55c0c03c8d7ba62bbd6e9fb23686 (apologies for the hack-like syntax) - the ‘every property must be a constructor parameter’ approach in the RFC seems like it would rapidly become unwieldy for classes with a large number of properties.

Regards,

• Fred

Hi,

I would need your help with one idea. I'm working on one RFC that I'm would
like to submit. Idea is that after you initialize object eg. after
constructor returns, object would be locked, and you wouldn't be able to
change properties on that object anymore. It would like this:

<?php

immutable class Email {

public $email;
public function __construct($email){
    $this->email = $email;
}

}
$email = new Email("example@email.com");

After instance of class is created, object is "frozen" so call like this

$email->email = "new@email.com";

Would result in error.

I have already implementation up to certain degree, but I need one advice
from more experienced developers. Where is the place where I could put
logic to lock object after the constructor has finished? Maybe in zend vm
on ZEND_NEW token?

Some constraints are needed:

1. Child class that extends immutable class must be defined as immutable
   also.
2. If property on immutable class contains object, it must be instance
   of immutable class.
3. You can not have immutability per property, it either whole class or
   none.

Thank you all in advance.

--
Silvio Marijić
Software Engineer
2e Systems

Hi Andre,

Here is RFC https://wiki.php.net/rfc/immutability and you have link to
implementation github. Any suggestions and feedback are more then welcome.

Best,
Silvio

Hi Silvio,

very nice work you guys did here! :)

Abstract classes are not mentioned at all in the RFC. However, there is
a test case from which it is clear that abstract classes cannot be
immutable. Are there any reasons for this restrictions?

What about array and resource values? Not mentioned in the RFC.

The fact that cloning is not possible should also be extended in the
RFC. I mean, it's clear to me but maybe not to others. Remember that the
RFC is the main source of information for the feature (e.g. to generate
documentation).

Why the restrictions that all properties of an immutable class that take
objects must be immutable too? It's clear why an immutable property must
contain an immutable class but the inheritance from the class to the
properties is not consistent with how things work. An immutable class
might want to contain an internal cache (e.g. flyweight pattern).

immutable final class Flyweight {

private static $instances = [];

public immutable $value;

private function __construct($value) {
  $this->value = $value;
}

public static function ENUM_ORD() {
  if (isset(self::$instances[1]) === false) {
    self::$instances[1] = new self(1);
  }

  return self::$instances[1];
}

}

$o1 = Flyweight::ENUM_ORD();
$o2 = Flyweight::ENUM_ORD();

var_dump($o1 === $o2); // bool(true)

Note that we could add the restriction that an immutable class that
should be used in a threading context must contain only immutable
properties in the future when the need arises. However, for now I do not
see the need to inherit the modifier from the class to its properties
and I see use cases where the developer wants more control.

The test cases cover the most stuff but not everything and could be
extended. There are other things with the PR but I will check it out and
create a PR against your branch with that so you can review it. (Might
take a while so bare with me.)

The RFC contains several grammatical issues. I could help you with that
too if you want.

There is a lot of diff noise in the ext/tokenizer/tokenizer_data.c file.

--
Richard "Fleshgrinder" Fussenegger

Well at the moment expection is thrown in case when you try to clone
immutable object. But you do seem to have valid point there regarding
__clone method. I'm definitely going to give it a thought.

Best,
Silvio.

2016-09-02 15:52 GMT+02:00 André Rømcke andre.romcke@ez.no:

On Sep 2, 2016, at 09:10 , Silvio Marijić marijic.silvio@gmail.com
wrote:
Hi Fleshgrinder,

Since Michal answered most of the questions, I'll just add some notes.
Initially I added restrictions to abstract classes, but I did think about
that over the last couple of days and couldn't find any concrete reason
for
that restriction, so I think I'm going to remove that. As far as cloning,
it is disabled for immutable objects, because you'll end up with the copy
of object that you can not modify. I did mention in Cons sections that
cloning is disabled, maybe it should be made more clear.

If there are use-cases for it, wouldn’t it also be safe that the clone
is allowed to be modified during __clone() and afterwards sealed? Like in
__construct().
And if you don’t want to allow cloning, throw in __clone.

Best,
André

I'd have to agree here. I love the idea of "lockable" immutable
objects. However, the __clone() method has to be a modifiable area just
like __construct() or else it's effectively useless for anything more
than a trivial object.

This was one of the main concerns with immutability in the PSR-7
discussions. Consider this sample class, with 8 properties (entirely
reasonable for a complex value object):

immutable class Record {
public $a;
public $b;
public $c;
public $d;
public $e;
public $f;
public $g;
public $h;

public function __construct($a, $b, $c, $d, $e, $f, $g, $h) {
$this->a = $a;
$this->b = $b;
$this->c = $c;
$this->d = $d;
$this->e = $e;
$this->f = $f;
$this->g = $g;
$this->h = $h;
}
}

Now I want a new value object that is the same, except that $d is
incremented by 2. That is, I'm building up the value object over time
rather than knowing everything at construct time. (This is exactly the
use case of PSR-7.) I have to do this:

$r1 = new Record(1, 2, 3, 4, 5, 6, 7, 8);

$r2 - new Record($r1->a, $r1->b, $r1->c, $r1->d + 2, $1->e, $r1->f,
$r1->g, $r1->h);

That's crazy clunky, and makes immutable objects not very useful.
Imagine a money object where you had to dissect it to its primitives,
tweak one, and then repackage it just to add a dollar figure to it.
That's not worth the benefit of being immutable.

The way PSR-7 addressed that (using fake-immutability, basically), was this:

class Response {
// ...

protected $statusCode;

public function withStatusCode($code) {
$new = clone($this);
$new->statusCode = $code;
return $new;
}
}

That is, outside of the object there's no way to modify it in place, but
it becomes super easy to get a slightly-modified version of the object:

$r2 = $r1->withStatusCode(418);

And because of PHP's copy-on-write support, it's actually surprisingly
cheap.

For language-level immutable objects, we would need some equivalent of
that behavior. I'm not sure exactly what form it should take (explicit
lock/unlock commands is all I can think of off hand, which I dislike),
but that's the use case that would need to be addressed.

--Larry Garfield

And also Fleshgrinder made a good point about comparing two immutable
objects. They should be compared based on value, not on identity.

2016-09-07 11:28 GMT+02:00 Silvio Marijić marijic.silvio@gmail.com:

Hi Stephen,

Cloning is disabled at the moment in implementation because you would end
up with a object that you can not change, so you have no use of that. I'll
change that as soon as we find some good solution for handling that. Your
example is not really clear to me. At what point we should unlock/lock
object based on your example?

DateTimeImmutable does not prevent cloning because immutability is
achieved by encapsulation, and we want to get rid of the need of
encapsulation in our implementation of immutable objects.

Best,
Silvio.

2016-09-07 11:05 GMT+02:00 Stephen Reay php-lists@koalephant.com:

(Sorry for any dupes, sent from wrong address originally)

From a developer point of view, I would suggest that a feature should aim
to be as clear to understand with as little “magic" as possible.

If the goal of an immutable class is to allow public properties to be
made read-only, my expectation would be that:

• write access to any public property from outside class context, is an
  error.

This seems to be pretty much accepted by everyone

• clone still works as expected

There has been some suggestion that clone $immutableObj should not be
allowed. Unless there is some specific language/engine gain by that, what
is the point of having this behaviour?
Existing built-in immutable classes (like DateTimeImmutable) do not
prevent cloning, so why should this?

• regular cloning from within class method(s) is the suggested way to
  provide “create a copy of the object with a new value” functionality.

This example was given before, effectively:

public function withValue($val) {
$clone = clone $this;
$clone->val = $val;

    return $clone;

}

On 7 Sep 2016, at 13:57, Michał Brzuchalski michal@brzuchalski.com
wrote:

06.09.2016 9:13 PM "Fleshgrinder" php@fleshgrinder.com napisał(a):

I understand the concerns of all of you very well and it's nice to see
a
discussion around this topic. Fun fact, we are not the only ones with
these issues: https://github.com/dotnet/roslyn/issues/159

How big of a need is it to allow returning $this instead of $clone,
and/or can that be internalized somehow as well? With copy-on-write,
is that really an issue beyond a micro-optimization?

I asked the same question before because I am also unable to answer
this
question regarding the engine.

However, for me it is more than micro-optimization, it is about
identity.

final class Immutable {
// ... the usual ...
public function withValue($value) {
$clone = clone $this;
$clone->value = $value;
return $clone;
}
}

$red = new Immutable('red');
$still_red = $red->withValue('red');

var_dump($red === $still_red); // bool(false)

This is a problem in terms of value objects and PHP still does not
allow
us operator overloading. A circumstance that I definitely want to
address in the near future.

But the keyword copy-on-write leads me to yet another proposal,
actually
your input led me to two new proposals.

Copy-on-Write (CoW)

Why are we even bothering on finding ways on making it hard for
developers while the solution to our problem is directly in front of
us:
PHP Strings!

AFAIK CoW in case of objects would be impossible to implement.

Every place in a PHP program refers to the same string if that string
is
the same string. In the second someone mutates that string in any way
she gets her own mutated reference to that string.

That's exactly how we could deal with immutable objects. Developers do
not need to take care of anything, they just write totally normal
objects and the engine takes care of everything.

This approach also has the advantage that the return value of any
method
is (as always) up to the developers.

(Cloning is disabled and results in an error as is because it makes no
sense at all.)

Identity

This directly leads to the second part of my thoughts and I already
touched that topic: identity. If we have two strings their binary
representation is always the same:

var_dump('string' === 'string'); // bool(true)

This is the exact behavior one wants for value objects too. Hence,
immutable objects should have this behavior since they identify
themselves by their values and not through instances. If I create two
instances of Money with the amount 10 and the Currency EUR then they
are
always the same, no matter what. This would also mean that no developer
ever needs to check if the new value is the same as the existing one,
nor does anyone ever has to implement the flyweight pattern for
immutable objects.

A last very important attribute is that it does not matter in which
thread an immutable value object is created because it always has the
same identity regardless of it.

This could easily be achieved by overwriting the object hashes
(spl_object_hash) with something that hashes based on the values, and
predictably across threads (UUIDs?).

Full Example

<?php

final immutable class ValueObject {

public $value;

public function __construct($value) {
$this->value = $value;
}

public function withValue($value) {
$this->value = $value;
}

}

class A {

public $vo;

public function __construct(ValueObject $vo) {
$this->vo = $vo;
}

}

class B {

public $vo;

public function __construct(ValueObject $vo) {
$this->vo = $vo;
}

}

$vo = new ValueObject(1);

$a = new A($vo);
$b = new B($vo);

var_dump($a->vo === $b->vo); // bool(true)

$a->vo->withValue(2);

var_dump($a->vo === $b->vo); // bool(false)

$a->vo->withValue(1);

var_dump($a->vo === $b->vo); // bool(true)

// :)

?>

--
Richard "Fleshgrinder" Fussenegger

--

--
Silvio Marijić
Software Engineer
2e Systems

--
Silvio Marijić
Software Engineer
2e Systems

Hi Stephen,

Cloning is disabled at the moment in implementation because you would end
up with a object that you can not change, so you have no use of that. I'll
change that as soon as we find some good solution for handling that. Your
example is not really clear to me. At what point we should unlock/lock
object based on your example?
what would happen if you tried to clone an immutable object, throw an
error ?
it means that you might have to use reflection to check if the object is
immutable before cloning it. otherwise making a class immutable would be
a BC

DateTimeImmutable does not prevent cloning because immutability is achieved
by encapsulation, and we want to get rid of the need of encapsulation in
our implementation of immutable objects.

Best,
Silvio.

2016-09-07 11:05 GMT+02:00 Stephen Reay php-lists@koalephant.com:

(Sorry for any dupes, sent from wrong address originally)

From a developer point of view, I would suggest that a feature should aim
to be as clear to understand with as little “magic" as possible.

If the goal of an immutable class is to allow public properties to be made
read-only, my expectation would be that:

• write access to any public property from outside class context, is an
  error.

This seems to be pretty much accepted by everyone

• clone still works as expected

There has been some suggestion that clone $immutableObj should not be
allowed. Unless there is some specific language/engine gain by that, what
is the point of having this behaviour?
Existing built-in immutable classes (like DateTimeImmutable) do not
prevent cloning, so why should this?

• regular cloning from within class method(s) is the suggested way to
  provide “create a copy of the object with a new value” functionality.

This example was given before, effectively:

public function withValue($val) {
$clone = clone $this;
$clone->val = $val;

     return $clone;

}

On 7 Sep 2016, at 13:57, Michał Brzuchalski michal@brzuchalski.com
wrote:
06.09.2016 9:13 PM "Fleshgrinder" php@fleshgrinder.com napisał(a):

I understand the concerns of all of you very well and it's nice to see a
discussion around this topic. Fun fact, we are not the only ones with
these issues: https://github.com/dotnet/roslyn/issues/159

How big of a need is it to allow returning $this instead of $clone,
and/or can that be internalized somehow as well? With copy-on-write,
is that really an issue beyond a micro-optimization?
I asked the same question before because I am also unable to answer this
question regarding the engine.

However, for me it is more than micro-optimization, it is about
identity.
final class Immutable {
// ... the usual ...
public function withValue($value) {
$clone = clone $this;
$clone->value = $value;
return $clone;
}
}

$red = new Immutable('red');
$still_red = $red->withValue('red');

var_dump($red === $still_red); // bool(false)

This is a problem in terms of value objects and PHP still does not allow
us operator overloading. A circumstance that I definitely want to
address in the near future.

But the keyword copy-on-write leads me to yet another proposal, actually
your input led me to two new proposals.

Copy-on-Write (CoW)

Why are we even bothering on finding ways on making it hard for
developers while the solution to our problem is directly in front of us:
PHP Strings!

AFAIK CoW in case of objects would be impossible to implement.

Every place in a PHP program refers to the same string if that string is
the same string. In the second someone mutates that string in any way
she gets her own mutated reference to that string.

That's exactly how we could deal with immutable objects. Developers do
not need to take care of anything, they just write totally normal
objects and the engine takes care of everything.

This approach also has the advantage that the return value of any method
is (as always) up to the developers.

(Cloning is disabled and results in an error as is because it makes no
sense at all.)

Identity

This directly leads to the second part of my thoughts and I already
touched that topic: identity. If we have two strings their binary
representation is always the same:

var_dump('string' === 'string'); // bool(true)

This is the exact behavior one wants for value objects too. Hence,
immutable objects should have this behavior since they identify
themselves by their values and not through instances. If I create two
instances of Money with the amount 10 and the Currency EUR then they are
always the same, no matter what. This would also mean that no developer
ever needs to check if the new value is the same as the existing one,
nor does anyone ever has to implement the flyweight pattern for
immutable objects.

A last very important attribute is that it does not matter in which
thread an immutable value object is created because it always has the
same identity regardless of it.

This could easily be achieved by overwriting the object hashes
(spl_object_hash) with something that hashes based on the values, and
predictably across threads (UUIDs?).

Full Example

<?php

final immutable class ValueObject {

public $value;

public function __construct($value) {
$this->value = $value;
}

public function withValue($value) {
$this->value = $value;
}

}

class A {

public $vo;

public function __construct(ValueObject $vo) {
$this->vo = $vo;
}

}

class B {

public $vo;

public function __construct(ValueObject $vo) {
$this->vo = $vo;
}

}

$vo = new ValueObject(1);

$a = new A($vo);
$b = new B($vo);

var_dump($a->vo === $b->vo); // bool(true)

$a->vo->withValue(2);

var_dump($a->vo === $b->vo); // bool(false)

$a->vo->withValue(1);

var_dump($a->vo === $b->vo); // bool(true)

// :)

?>

--
Richard "Fleshgrinder" Fussenegger

DateTimeImmutable does not prevent cloning because immutability is achieved
by encapsulation, and we want to get rid of the need of encapsulation in
our implementation of immutable objects.

What is the problem with 'encapsulation'? By that I mean creating
readonly result set from class and packaging it with just the links to
the functions that display those results. Nothing stopping the class
building multiple objects, and the construction code is unnecessary once
the target has been created. Simplifying access to the set of variables
making up the object might help with all the different options for
getters and the like, but essentially the object is just a set of
variables which build a result which may potentially just be a
pre-formatted string or a number. In my book date/time is still a 32bit
day count and 32bit time fraction so a DateTimeImmutable is just a 64bit
number ... which you can't write to.

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

@Mathieu,

Object can not be modified neither internally or externally, question is if
you clone object where should we allow modification of cloned object

(Sorry for any dupes, sent from wrong address originally)

From a developer point of view, I would suggest that a feature should
aim to be as clear to understand with as little “magic" as possible.

If the goal of an immutable class is to allow public properties to be
made read-only, my expectation would be that:

I don't think this is the goal, in immutable classes, the object itself
should not be able to alter itself either (whatever the visibility of the
property is)

• write access to any public property from outside class context, is an
  error.

This seems to be pretty much accepted by everyone

• clone still works as expected

There has been some suggestion that clone $immutableObj should not be
allowed. Unless there is some specific language/engine gain by that, what
is the point of having this behaviour?
Existing built-in immutable classes (like DateTimeImmutable) do not
prevent cloning, so why should this?

• regular cloning from within class method(s) is the suggested way to
  provide “create a copy of the object with a new value” functionality.

This example was given before, effectively:

public function withValue($val) {
$clone = clone $this;
$clone->val = $val;

    return $clone;

}

On 7 Sep 2016, at 13:57, Michał Brzuchalski michal@brzuchalski.com

wrote:

06.09.2016 9:13 PM "Fleshgrinder" php@fleshgrinder.com napisał(a):

I understand the concerns of all of you very well and it's nice to see a
discussion around this topic. Fun fact, we are not the only ones with
these issues: https://github.com/dotnet/roslyn/issues/159

How big of a need is it to allow returning $this instead of $clone,
and/or can that be internalized somehow as well? With copy-on-write,
is that really an issue beyond a micro-optimization?

I asked the same question before because I am also unable to answer this
question regarding the engine.

However, for me it is more than micro-optimization, it is about
identity.

final class Immutable {
// ... the usual ...
public function withValue($value) {
$clone = clone $this;
$clone->value = $value;
return $clone;
}
}

$red = new Immutable('red');
$still_red = $red->withValue('red');

var_dump($red === $still_red); // bool(false)

This is a problem in terms of value objects and PHP still does not allow
us operator overloading. A circumstance that I definitely want to
address in the near future.

But the keyword copy-on-write leads me to yet another proposal, actually
your input led me to two new proposals.

Copy-on-Write (CoW)

Why are we even bothering on finding ways on making it hard for
developers while the solution to our problem is directly in front of us:
PHP Strings!

AFAIK CoW in case of objects would be impossible to implement.

Every place in a PHP program refers to the same string if that string is

the same string. In the second someone mutates that string in any way
she gets her own mutated reference to that string.

That's exactly how we could deal with immutable objects. Developers do
not need to take care of anything, they just write totally normal
objects and the engine takes care of everything.

This approach also has the advantage that the return value of any method
is (as always) up to the developers.

(Cloning is disabled and results in an error as is because it makes no
sense at all.)

Identity

This directly leads to the second part of my thoughts and I already
touched that topic: identity. If we have two strings their binary
representation is always the same:

var_dump('string' === 'string'); // bool(true)

This is the exact behavior one wants for value objects too. Hence,
immutable objects should have this behavior since they identify
themselves by their values and not through instances. If I create two
instances of Money with the amount 10 and the Currency EUR then they are
always the same, no matter what. This would also mean that no developer
ever needs to check if the new value is the same as the existing one,
nor does anyone ever has to implement the flyweight pattern for
immutable objects.

A last very important attribute is that it does not matter in which
thread an immutable value object is created because it always has the
same identity regardless of it.

This could easily be achieved by overwriting the object hashes
(spl_object_hash) with something that hashes based on the values, and
predictably across threads (UUIDs?).

Full Example

<?php

final immutable class ValueObject {

public $value;

public function __construct($value) {
$this->value = $value;
}

public function withValue($value) {
$this->value = $value;
}

}

class A {

public $vo;

public function __construct(ValueObject $vo) {
$this->vo = $vo;
}

}

class B {

public $vo;

public function __construct(ValueObject $vo) {
$this->vo = $vo;
}

}

$vo = new ValueObject(1);

$a = new A($vo);
$b = new B($vo);

var_dump($a->vo === $b->vo); // bool(true)

$a->vo->withValue(2);

var_dump($a->vo === $b->vo); // bool(false)

$a->vo->withValue(1);

var_dump($a->vo === $b->vo); // bool(true)

// :)

?>

--
Richard "Fleshgrinder" Fussenegger

Hi,

Frozing an immutable object after it's creation is most important feature
of Immutable Classes.
Without it you cannot have guarantee it's internal state is consistent as
it was during creation.
Having methods access to write is quite dangerous - think about CLosure
binded to immutable object - there is a way to change internal state of
such object, and you've broken immutability in it.

Changing object state is reasonable only on clones, because you newer know
what references to original object.
There can be cloning objects as they are now - I don't see it usefull, but
if somebody really want's it, why not.

IMHO providing method modificator for changing object in context of newly
created clone is the best solution. The keyword for it isn't chosen yet, we
may discuss it or even vote for it. For now we can call it anyway while
keeping in mind it may change during voting.

2016-09-07 12:43 GMT+02:00 Silvio Marijić marijic.silvio@gmail.com:

@Stephan

I am against that any kind of method can make modification on original
object.

Cloning can be allowed but for this use case where you would pass
properties that are changing, we would have to modify syntax of clone

Hey Matheiu, Silvio,

That is my main concern with the inability to clone from outside the
class. I don’t think immutable should cause an error in this situation -
if
you really don’t want to allow users to create objects they can’t modify
(which I understand) could clone on an immutable object from outside the
class, simply return the object itself ?

Re: immutable only externally - yes, as I mentioned I can understand that
would be a deal-break for some. In that situation, I’d be happy with some
way to indicate that a method can make changes. Would this then mean that
such a method could modify the object itself, rather than the clone?

Cheers

Stephen

Hi Stephen,

Cloning is disabled at the moment in implementation because you would
end
up with a object that you can not change, so you have no use of that.
I'll
change that as soon as we find some good solution for handling that.
Your
example is not really clear to me. At what point we should unlock/lock
object based on your example?
what would happen if you tried to clone an immutable object, throw an
error ?
it means that you might have to use reflection to check if the object
is
immutable before cloning it. otherwise making a class immutable would be
a
BC

DateTimeImmutable does not prevent cloning because immutability is
achieved
by encapsulation, and we want to get rid of the need of encapsulation
in
our implementation of immutable objects.

Best,
Silvio.

2016-09-07 11:05 GMT+02:00 Stephen Reay php-lists@koalephant.com:

(Sorry for any dupes, sent from wrong address originally)

From a developer point of view, I would suggest that a feature should
aim
to be as clear to understand with as little “magic" as possible.

If the goal of an immutable class is to allow public properties to be
made
read-only, my expectation would be that:

• write access to any public property from outside class context, is
  an
  error.

This seems to be pretty much accepted by everyone

• clone still works as expected

There has been some suggestion that clone $immutableObj should not be
allowed. Unless there is some specific language/engine gain by that,
what
is the point of having this behaviour?
Existing built-in immutable classes (like DateTimeImmutable) do not
prevent cloning, so why should this?

• regular cloning from within class method(s) is the suggested way to
  provide “create a copy of the object with a new value” functionality.

This example was given before, effectively:

public function withValue($val) {
$clone = clone $this;
$clone->val = $val;

    return $clone;

}

On 7 Sep 2016, at 13:57, Michał Brzuchalski <michal@brzuchalski.com

wrote:

06.09.2016 9:13 PM "Fleshgrinder" php@fleshgrinder.com
napisał(a):

I understand the concerns of all of you very well and it's nice to
see a
discussion around this topic. Fun fact, we are not the only ones
with
these issues: https://github.com/dotnet/roslyn/issues/159

How big of a need is it to allow returning $this instead of
$clone,
and/or can that be internalized somehow as well? With
copy-on-write,
is that really an issue beyond a micro-optimization?
I asked the same question before because I am also unable to answer
this
question regarding the engine.

However, for me it is more than micro-optimization, it is about
identity.
final class Immutable {
// ... the usual ...
public function withValue($value) {
$clone = clone $this;
$clone->value = $value;
return $clone;
}
}

$red = new Immutable('red');
$still_red = $red->withValue('red');

var_dump($red === $still_red); // bool(false)

This is a problem in terms of value objects and PHP still does not
allow
us operator overloading. A circumstance that I definitely want to
address in the near future.

But the keyword copy-on-write leads me to yet another proposal,
actually
your input led me to two new proposals.

Copy-on-Write (CoW)

Why are we even bothering on finding ways on making it hard for
developers while the solution to our problem is directly in front
of
us:
PHP Strings!

AFAIK CoW in case of objects would be impossible to implement.

Every place in a PHP program refers to the same string if that
string is
the same string. In the second someone mutates that string in any
way
she gets her own mutated reference to that string.

That's exactly how we could deal with immutable objects. Developers
do
not need to take care of anything, they just write totally normal
objects and the engine takes care of everything.

This approach also has the advantage that the return value of any
method
is (as always) up to the developers.

(Cloning is disabled and results in an error as is because it makes
no
sense at all.)

Identity

This directly leads to the second part of my thoughts and I already
touched that topic: identity. If we have two strings their binary
representation is always the same:

var_dump('string' === 'string'); // bool(true)

This is the exact behavior one wants for value objects too. Hence,
immutable objects should have this behavior since they identify
themselves by their values and not through instances. If I create
two
instances of Money with the amount 10 and the Currency EUR then
they
are
always the same, no matter what. This would also mean that no
developer
ever needs to check if the new value is the same as the existing
one,
nor does anyone ever has to implement the flyweight pattern for
immutable objects.

A last very important attribute is that it does not matter in which
thread an immutable value object is created because it always has
the
same identity regardless of it.

This could easily be achieved by overwriting the object hashes
(spl_object_hash) with something that hashes based on the values,
and
predictably across threads (UUIDs?).

Full Example

<?php

final immutable class ValueObject {

public $value;

public function __construct($value) {
$this->value = $value;
}

public function withValue($value) {
$this->value = $value;
}

}

class A {

public $vo;

public function __construct(ValueObject $vo) {
$this->vo = $vo;
}

}

class B {

public $vo;

public function __construct(ValueObject $vo) {
$this->vo = $vo;
}

}

$vo = new ValueObject(1);

$a = new A($vo);
$b = new B($vo);

var_dump($a->vo === $b->vo); // bool(true)

$a->vo->withValue(2);

var_dump($a->vo === $b->vo); // bool(false)

$a->vo->withValue(1);

var_dump($a->vo === $b->vo); // bool(true)

// :)

?>

--
Richard "Fleshgrinder" Fussenegger

--

--
regards / pozdrawiam,

Michał Brzuchalski
brzuchalski.com

Thanks a lot for your feedback.

I like the clone idea too and I also see no harm in allowing them in any
context rather than only in immutable classes. I am really against the
transformer keyword, don't ask me why, I just don't like it at all. :P

I mentioned before that PHP should allow for operator overloading since
there are other value object use cases that are even simpler than your
HTTP header result: any value object that is case insensitive. Doh!

I do like the https://wiki.php.net/rfc/comparable RFC but we would need
more for value objects to be truly useful.

class A {

// $this == $other
function __isEqual($other);

// $this === $other
function __isIdentical($other);

}

This will be very hard to get through though because it's operator
overloading. I am currently already doing this in many of my value
objects, although I usually implement an equals method only and let it
take care of equals and identity checks at the same time.

final class HexNumber {

private $val;

public function __construct(string $hex) {
  $this->val = strtolower($hex);
}

public function equals($other) {
  if ($other instanceof self) {
    return $other->val === $this->val;
  }

  if (is_string($other)) {
    return strtolower($other) === $this->val;
  }

  return false;
}

}

$hn = new HexNumber('ff00');
var_dump($hn->equals('FF00')); // bool(true)

However, this is not necessarily exactly what you want in every context,
hence, the proposal for operator overloading.

That being said, I agree that this could (and probably should) be
tackled in another RFC. Immutable classes do not have to solve every
problem.

--
Richard "Fleshgrinder" Fussenegger

Ah, I did see that one, but there was a lot of discussion after it
so I thought the idea evolved. Response below based on skimming the
responses after that as well...

It sounds like there's more that needs to go on, though. It sounds
like that thread is suggesting that $this in a method of an
immutable object is always cloned, which seems excessive to me.

The point about identity is well-taken. However, it's more complex
on objects because equality is not as simple as it is on strings.
Two objects can be logically identical but physically different. For
instance:

class HttpHeaders {
public $attributes = [];
}

$a = new HttpHeaders();
$a->attributes['foo'] = 'bar';
$a->attributes['baz'] = 'buzz';

$b = new HttpHeaders();
$b->attributes['baz'] = 'buzz';
$b->attributes['foo'] = 'bar';

$a and $b are now not physically identical, since their attributes
array is in a different order. However, header order doesn't matter
in HTTP, or rather isn't supposed to. (Modulo buggy
implementations, of course.) So are $a and $b identical? I could
very easily argue both directions on that. Physical identity would
be easier to automate checking in the engine; logical identity would
require user-space code to make such decisions.

From the discussion of "transformer" methods, I'd propose a
slightly different keyword. To wit:

1. A class marked as "immutable" may not have any of its properties
   altered, EXCEPT in certain unlocked scopes. The constructor is an
   unlocked scope.

2. A method may be marked "clone": public clone function foo() {}. A
   clone method is identical to any other method except that A) $this
   in its scope is not the original object, but the result of
   clone($this); B) A clone method is an unlocked scope, so modifying
   $this (the clone) is legal. That is more self-descriptive than
   "transformer", and also doesn't require a new keyword. (By
   implication, clone and static are mutually exclusive since clone
   requires an object to clone.)

I don't know that there are any other unlocked scopes to consider...

#2 does leave us with the identity question that Richard raises, in
that returning an unmodified $this from a clone method still creates
a new object identity. However, I posit that is to be expected. In
Python, eg, while some built-in objects are immutable they are not,
necessarily, always the same physical object in memory. (999+1 is
not the same object as 1000, but 1+2 and 2 likely will be due to
internal engine optimizations.) You need to do a value comparison
of them.

I don't see the identity case being resolved without an __identity()
method, or similar. Which could be useful in its own right so I'm
not necessarily against it, but it's an extra, and I'd argue
optional, piece of the puzzle.

Related to whether or not the properties of an object may be mutable
(arrays, other objects, etc.), they would in practice probably need
to blacklist resources. We ran into that issue in PSR-7, where the
body stream has to be mutable, because streams. Since PSR-7 is
based on PHP 5.3 that doesn't cause any syntactic issues, just
logical issues. If the classes were marked immutable explicitly, it
likely would be a problem since the streams cannot be immutable,
thus they can't be used on an immutable object. Which is... very
sad making. :-(

--Larry Garfield

--

I like your suggestion with the ‘clone’ keyword on methods.

As I said before, I think it’s a mis-step to prevent manual cloning
at the engine level (even if the result is that you return the same
instance) - there is bound to be user land code that clones
objects. Without this, any use of clone in a distributed
library/framework will have to do a check to see if an object (except
those accepting final classes of known definition) is immutable
before attempting to clone it.

I think most people in the thread have agreed that blocking clone() is
unnecessary, the RFC just hasn't been updated yet. With a clone
method, an external clone becomes basically a pointless but harmless
operation, I'd think. A clone within the class would be fairly
nonsensical, except for the clone methods.
I agree that blocking clone seems unnecessary. I also don't see why it
is useful to have "clone" methods. Why not let "clone $this" produce a
copy that is open to modification within the scope it's cloned in ? or,
why would you limit yourself to one clone per method call ? maybe there
is something I'm missing but I don't get why introducing a new method
annotation is useful. it looks like an implementation details (using
clone instead of new) of the method is leaking