Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97376
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: <2c979395-7b5c-f98e-57a4-ee8b8bd33e74@fleshgrinder.com>
References: <CAA69SC7sfDOyd1oMTGF7gHLe+MXbtr4nqpQ0eufxKyWChrm9Jg@mail.gmail.com>
 <2c979395-7b5c-f98e-57a4-ee8b8bd33e74@fleshgrinder.com>
Date: Mon, 12 Dec 2016 20:19:50 +0100
Message-ID: <CAA69SC4uxTrR1njJVj6M0tuCESDZykd8Hk_BRR1kgc2w7UbkPw@mail.gmail.com>
To: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113f6a1ce146c505437afc4b
Subject: Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties
From: marijic.silvio@gmail.com (=?UTF-8?Q?Silvio_Mariji=C4=87?=)

--001a113f6a1ce146c505437afc4b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

@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>:

> On 12/11/2016 5:57 PM, Silvio Mariji=C4=87 wrote:
> > 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
>



--=20
Silvio Mariji=C4=87
Software Engineer
2e Systems

--001a113f6a1ce146c505437afc4b--