[RFC][DISCUSSION] - Immutable classes and properties

9 years ago by marijic.silvio@gmail.com — view source — reply

unread

Hi,

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

Cheers

9 years ago by Larry Garfield — view source — reply

unread

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

9 years ago by Marcio Almada — view source — reply

unread

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.

9 years ago by marijic.silvio@gmail.com — view source — reply

unread

@Larry, first of all thanks for pointing out grammar issues, I will correct
them. Now, regarding cloning of the immutable object, I'm aware of that
issue and I'm not sure if we could even use clone operation for this
purpose, I do have one proposal for that matter, consider example:

immutable class User {
public $firstname;
public $lastname;
public $email;
public function __construct($firstname, $lastname, $email){
//
}
}

$user = new User('Foo', 'Bar', 'foo@bar.com');

$new = copy($user, ['firstname' => 'John', 'email' => 'john@bar.com'])

Copy function would take as a first argument an immutable object and as a
second argument associative array where keys represent property names and
values specified will be assigned to those properties on a new object.

@Marcio I will submit PR, have you found bug or?

Cheers

2016-12-11 23:35 GMT+01:00 Marcio Almada marcio.web2@gmail.com:

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/immut
ability

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.

--
Silvio Marijić
Software Engineer
2e Systems

9 years ago by Fleshgrinder — view source — reply

unread

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

9 years ago by marijic.silvio@gmail.com — view source — reply

unread

@Fleshgrinder

My opinion on that subject is still that features are mostly complete but
I'am willing to find also solution to ease modifying.
Modify function does not modify object in any way, it will operate on the
clone of the object and this was just prototype. Moreover it should be
restricted to be only callable from the scope of the object. Introducing
method modifier causes more problems then it solves, and has whole another
level of complexity. Regarding changing keyword, 'data' does not fit
because object is behaviour + data, with behaviour beeing (or at least it
should be) at the first place. Value can imply or create confusion with
Value Objects, on the other hand immutable clearly states what it is.

Cheers,

2016-12-12 19:44 GMT+01:00 Fleshgrinder php@fleshgrinder.com:

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

--
Silvio Marijić
Software Engineer
2e Systems

9 years ago by Fleshgrinder — view source — reply

unread

@Fleshgrinder

My opinion on that subject is still that features are mostly complete but
I'am willing to find also solution to ease modifying.
Modify function does not modify object in any way, it will operate on the
clone of the object and this was just prototype. Moreover it should be
restricted to be only callable from the scope of the object. Introducing
method modifier causes more problems then it solves, and has whole another
level of complexity. Regarding changing keyword, 'data' does not fit
because object is behaviour + data, with behaviour beeing (or at least it
should be) at the first place. Value can imply or create confusion with
Value Objects, on the other hand immutable clearly states what it is.

Cheers,

The term data class comes from data transfer object (DTO). Uncle Bob
uses the term extensively in his books.

https://sourcemaking.com/refactoring/smells/data-class
https://kotlinlang.org/docs/reference/data-classes.html
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.idas200/underdc.htm

So it would be rather $this->modify() or $this->copy() and not
simply modify() nor copy(). ;)

The problem persists that you end up with lots of magic strings ... :(

--
Richard "Fleshgrinder" Fussenegger

9 years ago by Andrea Faulds — view source — reply

unread

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/

9 years ago by Paul Jones — view source — reply

unread

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

Which subverts its overall promise of immutability (and the streams are not the only place where the promise of immutability is subverted).

--
Paul M. Jones
pmjones88@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

9 years ago by marijic.silvio@gmail.com — view source — reply

unread

After much thinking regarding array in immutable objects I'm thinking of
revoking this RFC. If someone has some suggestion on that matter now is the
time, but otherwise my work is done on this one.

Cheers,

2016-12-12 20:56 GMT+01:00 Paul Jones pmjones88@gmail.com:

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

Which subverts its overall promise of immutability (and the streams are
not the only place where the promise of immutability is subverted).

--
Paul M. Jones
pmjones88@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

--

--
Silvio Marijić
Software Engineer
2e Systems

9 years ago by Markus Fischer — view source — reply

unread

Hello,

After much thinking regarding array in immutable objects I'm thinking of
revoking this RFC. If someone has some suggestion on that matter now is the
time, but otherwise my work is done on this one.

It would be nice if you could summarize the feedback into the RFC too
(i.e. the "Cons" points), maybe someone wants to pick it up later or
learn from it.

And thanks for the effort!

Markus

9 years ago by Yasuo Ohgaki — view source — reply

unread

Hi Silvio,

On Tue, Dec 13, 2016 at 6:17 PM, Silvio Marijić marijic.silvio@gmail.com
wrote:

After much thinking regarding array in immutable objects I'm thinking of
revoking this RFC. If someone has some suggestion on that matter now is the
time, but otherwise my work is done on this one.

It may be good to start from constant scalars.
ES6 has "let" and "const". PHP has "const", but PHP's constant does not
have scope other than class. It would be nice if const can be used like JS.

e.g. Following is syntax error.
<?php
function foo($v) {
const v=$v;
// Some complex code here.
return v * $var;
}

var_dump(foo(123));
?>

It would be large enough changes for 8.0, though.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

9 years ago by marijic.silvio@gmail.com — view source — reply

unread

Hi Yasuo,

Yes, that looks like interesting idea. I can open another RFC and start
working on that one, if there is a interest for that. Why can't we fit that
into 7.2 ?

Cheers,

2017-01-17 10:12 GMT+01:00 Yasuo Ohgaki yohgaki@ohgaki.net:

Hi Silvio,

On Tue, Dec 13, 2016 at 6:17 PM, Silvio Marijić marijic.silvio@gmail.com
wrote:

After much thinking regarding array in immutable objects I'm thinking of
revoking this RFC. If someone has some suggestion on that matter now is
the
time, but otherwise my work is done on this one.

It may be good to start from constant scalars.
ES6 has "let" and "const". PHP has "const", but PHP's constant does not
have scope other than class. It would be nice if const can be used like JS.

e.g. Following is syntax error.
<?php
function foo($v) {
const v=$v;
// Some complex code here.
return v * $var;
}

var_dump(foo(123));
?>

It would be large enough changes for 8.0, though.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--
Silvio Marijić
Software Engineer
2e Systems

9 years ago by Andrea Faulds — view source — reply

unread

Hi,

Paul Jones wrote:

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

Which subverts its overall promise of immutability (and the streams are not the only place where the promise of immutability is subverted).

Indeed. It's not necessarily a good feature, don't get me wrong.

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

9 years ago by Stanislav Malyshev — view source — reply

unread

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

9 years ago by Larry Garfield — view source — reply

unread

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

9 years ago by marijic.silvio@gmail.com — view source — reply

unread

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

9 years ago by Mathieu Rochette — view source — reply

unread

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?
well that's just my opinion but I don't think they depend on each other,
this rfc seems useful on its own. The "clone" one might depends on this
one but it does not need to either (otoh it certainly would be much
more useful with immutable classes than mutable classes)

plus, this part might already trigger enough discussion and adding
everything at once might get confusion. I can think of : clone, late
initialization, DateTimeImmutable and probably other subjects that could
make the discussion noisy

I'm not as familiar as you are with this mailing list so I might very
well be wrong too ^^

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

Assuming this was intended for the list...
it was, thank you

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

--

--
Mathieu Rochette

9 years ago by Davey Shafik — view source — reply

unread

On Sun, Dec 11, 2016 at 7:40 PM, Mathieu Rochette mathieu@texthtml.net
wrote:

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?
well that's just my opinion but I don't think they depend on each other,
this rfc seems useful on its own. The "clone" one might depends on this
one but it does not need to either (otoh it certainly would be much
more useful with immutable classes than mutable classes)

plus, this part might already trigger enough discussion and adding
everything at once might get confusion. I can think of : clone, late
initialization, DateTimeImmutable and probably other subjects that could
make the discussion noisy

I'm not as familiar as you are with this mailing list so I might very
well be wrong too ^^

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

Assuming this was intended for the list...
it was, thank you

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.

I wonder if we can essentially make all public methods act like they are
static (no access to $this) and then use something like:

immutable class Foo {
protected $bar;
public function getBar() with (Foo $instance): string // $instance is
a clone of $this
{
// context == $instance, so access to private/protected
return $instance->bar;
}

public function withBar($bar) with (Foo $instance): Foo
{
     $instance->bar = $bar; // Allowed as we're in scope
     return $instance;
}

}

Only operations in the scope of the class itself (and it's descendants,
adhering to standard visibility rules) can make changes on the cloned
variant. The with ($instance) is optional, $instance is just a variable
name. In reality you'll want to use it most of the time I imagine.

I suppose you can re-use the use keyword here too.

Also, this shouldn't allow for immutable properties.

Another option is to look at the way that HHVM does immutable types, though
that is file based.

Davey

9 years ago by marijic.silvio@gmail.com — view source — reply

unread

@Davey,

There was similar suggestion that $this represents clone of the object. I
think that is a bit vague, and I'am not sure about the 'scope' you refer to
because 'double scoping' could be also a reason to downvote this rfc and it
can lead to confusion in my opinion. I will check HHVM also.

Regarding my proposal above, since copy() would essentially operate only on
immutable objects, why not put it only there. So you would be able to make
a call like this one $immutable->copy(array $args); or $this->copy(array
$args); depending on whether you are inside let's say with* method or
outside of the object.

2016-12-12 6:58 GMT+01:00 Davey Shafik davey@php.net:

On Sun, Dec 11, 2016 at 7:40 PM, Mathieu Rochette mathieu@texthtml.net
wrote:

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?
well that's just my opinion but I don't think they depend on each other,
this rfc seems useful on its own. The "clone" one might depends on this
one but it does not need to either (otoh it certainly would be much
more useful with immutable classes than mutable classes)

plus, this part might already trigger enough discussion and adding
everything at once might get confusion. I can think of : clone, late
initialization, DateTimeImmutable and probably other subjects that could
make the discussion noisy

I'm not as familiar as you are with this mailing list so I might very
well be wrong too ^^

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

Assuming this was intended for the list...
it was, thank you

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.

I wonder if we can essentially make all public methods act like they are
static (no access to $this) and then use something like:

immutable class Foo {
protected $bar;
public function getBar() with (Foo $instance): string // $instance is
a clone of $this
{
// context == $instance, so access to private/protected
return $instance->bar;
}
public function withBar($bar) with (Foo $instance): Foo
{
     $instance->bar = $bar; // Allowed as we're in scope
     return $instance;
}
}

Only operations in the scope of the class itself (and it's descendants,
adhering to standard visibility rules) can make changes on the cloned
variant. The with ($instance) is optional, $instance is just a variable
name. In reality you'll want to use it most of the time I imagine.

I suppose you can re-use the use keyword here too.

Also, this shouldn't allow for immutable properties.

Another option is to look at the way that HHVM does immutable types,
though that is file based.

Davey

--
Silvio Marijić
Software Engineer
2e Systems

9 years ago by Rowan Collins — view source — reply

unread

Regarding my proposal above, since copy() would essentially operate
only on
immutable objects, why not put it only there. So you would be able to
make
a call like this one $immutable->copy(array $args); or
$this->copy(array
$args); depending on whether you are inside let's say with* method or
outside of the object.

If users of the object can set arbitrary (public) properties this way, then you've thrown away a bunch of the free encapsulation the immutable keyword gave you in the first place. What you get is an enforced copy-on-write, where you can set the properties to whatever state you like, just not using normal object passing semantics. That's very different from what the RFC shows, which are properties which are publicly readable, but whose state is exclusively controlled by the class (and its descendants).

PS The rule on this mailing list is too always reply below the text you're replying to.

--
Rowan Collins
[IMSoP]

9 years ago by marijic.silvio@gmail.com — view source — reply

unread

2016-12-12 15:14 GMT+01:00 Rowan Collins rowan.collins@gmail.com:

On 12 December 2016 09:11:17 GMT+00:00, "Silvio Marijić" <
marijic.silvio@gmail.com> wrote:

Regarding my proposal above, since copy() would essentially operate
only on
immutable objects, why not put it only there. So you would be able to
make
a call like this one $immutable->copy(array $args); or
$this->copy(array
$args); depending on whether you are inside let's say with* method or
outside of the object.

If users of the object can set arbitrary (public) properties this way,
then you've thrown away a bunch of the free encapsulation the immutable
keyword gave you in the first place. What you get is an enforced
copy-on-write, where you can set the properties to whatever state you like,
just not using normal object passing semantics. That's very different from
what the RFC shows, which are properties which are publicly readable, but
whose state is exclusively controlled by the class (and its descendants).

PS The rule on this mailing list is too always reply below the text
you're replying to.

--
Rowan Collins
[IMSoP]

--

I understand that, but I think we'll have to meet in the middle. How would
you handle situation where for one little change you have to manually
recreate not so trivial object with a lot of arguments ? I don't think that
should be a deal breaker for this RFC but I do agree that we should try to
find solution to bridge that gap and put that aside in a other rfc.

--
Silvio Marijić
Software Engineer
2e Systems

9 years ago by Rowan Collins — view source — reply

unread

I understand that, but I think we'll have to meet in the middle. How
would
you handle situation where for one little change you have to manually
recreate not so trivial object with a lot of arguments ? I don't think
that
should be a deal breaker for this RFC but I do agree that we should try
to
find solution to bridge that gap and put that aside in a other rfc.

I think there needs to be some "escape hatch" that the author of the class itself can use and control. For instance, a keyword on methods that marks them as a kind of copy constructor, giving them the same abilities as __construct has.

Regards,

--
Rowan Collins
[IMSoP]

9 years ago by marijic.silvio@gmail.com — view source — reply

unread

2016-12-12 15:14 GMT+01:00 Rowan Collins rowan.collins@gmail.com:

On 12 December 2016 09:11:17 GMT+00:00, "Silvio Marijić" <
marijic.silvio@gmail.com> wrote:

Regarding my proposal above, since copy() would essentially operate
only on
immutable objects, why not put it only there. So you would be able to
make
a call like this one $immutable->copy(array $args); or
$this->copy(array
$args); depending on whether you are inside let's say with* method or
outside of the object.

If users of the object can set arbitrary (public) properties this way,
then you've thrown away a bunch of the free encapsulation the immutable
keyword gave you in the first place. What you get is an enforced
copy-on-write, where you can set the properties to whatever state you like,
just not using normal object passing semantics. That's very different from
what the RFC shows, which are properties which are publicly readable, but
whose state is exclusively controlled by the class (and its descendants).

PS The rule on this mailing list is too always reply below the text
you're replying to.

I understand that, but I think we'll have to meet in the middle. How would
you handle situation where for one little change you have to manually
recreate not so trivial object with a lot of arguments ? I don't think that
should be a deal breaker for this RFC but I do agree that we should try to
find solution to bridge that gap and put that aside in a other rfc.

Rowan Collins
[IMSoP]

--

--
Silvio Marijić
Software Engineer
2e Systems

9 years ago by marijic.silvio@gmail.com — view source — reply

unread

Hi, this would be basic implementation of 'modify' function which would
operate on cloned object

PHP_FUNCTION(modify)
{
zval *obj,
*properties,
*entry;
zend_long h;
zend_string *key;

   if (zend_parse_parameters(ZEND_NUM_ARGS(), "oa", &obj, &properties)

== FAILURE) {
return;
}

ZEND_HASH_FOREACH_KEY_VAL_IND(Z_ARRVAL_P(properties), h, key, entry) {
zval member;
ZVAL_STR(&member, key);
zend_std_write_property(obj, &member, entry, NULL);
zval_ptr_dtor(&member);
} ZEND_HASH_FOREACH_END();

RETVAL_OBJ(Z_OBJ_P(obj));
}

immutable class User{
public $firstname;
public $lastname;

public function __construct($firstname, $lastname){}
public function withFirstName($firstname){
return modify($this, ['firstname' => $firstname]);
}
}

$user = new User('John', 'Doe');
$new = $user->withFirstName('Foo');

Any feedback?

2016-12-12 15:43 GMT+01:00 Silvio Marijić marijic.silvio@gmail.com:

2016-12-12 15:14 GMT+01:00 Rowan Collins rowan.collins@gmail.com:

On 12 December 2016 09:11:17 GMT+00:00, "Silvio Marijić" <
marijic.silvio@gmail.com> wrote:

Regarding my proposal above, since copy() would essentially operate
only on
immutable objects, why not put it only there. So you would be able to
make
a call like this one $immutable->copy(array $args); or
$this->copy(array
$args); depending on whether you are inside let's say with* method or
outside of the object.

If users of the object can set arbitrary (public) properties this way,
then you've thrown away a bunch of the free encapsulation the immutable
keyword gave you in the first place. What you get is an enforced
copy-on-write, where you can set the properties to whatever state you like,
just not using normal object passing semantics. That's very different from
what the RFC shows, which are properties which are publicly readable, but
whose state is exclusively controlled by the class (and its descendants).

PS The rule on this mailing list is too always reply below the text
you're replying to.

I understand that, but I think we'll have to meet in the middle. How
would you handle situation where for one little change you have to manually
recreate not so trivial object with a lot of arguments ? I don't think that
should be a deal breaker for this RFC but I do agree that we should try to
find solution to bridge that gap and put that aside in a other rfc.

--

Rowan Collins
[IMSoP]

--

--
Silvio Marijić
Software Engineer
2e Systems

--
Silvio Marijić
Software Engineer
2e Systems

[RFC][DISCUSSION] - Immutable classes and properties View as Markdown