Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97367
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <76C07EDB-56B3-46AB-A5C1-92485B32C113@gmail.com>
References: <CAA69SC7sfDOyd1oMTGF7gHLe+MXbtr4nqpQ0eufxKyWChrm9Jg@mail.gmail.com>
 <1807f949-81d3-f2c4-8706-0fdade3ea51d@garfieldtech.com> <4635ac4b-844a-b023-5ad9-e8524a156404@texthtml.net>
 <fa72c5af-822c-3716-f562-b069ba5ef9b8@garfieldtech.com> <CAA69SC477BGX-8tYGRrv-o1RYYzC3wzD-vWUWR9Gbpcz+QStxQ@mail.gmail.com>
 <79ea244b-9fe7-5b05-d429-bf5585215542@texthtml.net> <CANaX5ne-kvAMzLuc3+tpuXr3vGcdfC1xeSZg42=U1CWzXJMbcA@mail.gmail.com>
 <CAA69SC4MLO7KLWuMcQZw2g86tvbjK6rtxSQsfdN0ApmKM8=4=w@mail.gmail.com> <76C07EDB-56B3-46AB-A5C1-92485B32C113@gmail.com>
Date: Mon, 12 Dec 2016 15:43:24 +0100
Message-ID: <CAA69SC6qDdzDrUB6pdnyNfGaYm6HVrVDOrTci5XjjYmz+GD7mw@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113f6a1c3dff210543772099
Subject: Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties
From: marijic.silvio@gmail.com (=?UTF-8?Q?Silvio_Mariji=C4=87?=)

--001a113f6a1c3dff210543772099
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=C4=87" <
> 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 lik=
e,
> just not using normal object passing semantics. That's very different fro=
m
> 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 woul=
d
> 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 th=
at
> should be a deal breaker for this RFC but I do agree that we should try t=
o
> find solution to bridge that gap and put that aside in a other rfc.
>
--
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


--=20
Silvio Mariji=C4=87
Software Engineer
2e Systems

--001a113f6a1c3dff210543772099--