Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95552
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CABdc3Wp13y2bjC-T3PuiXLvN_3rvenQ3J9f0562+xu4Yij70wg@mail.gmail.com>
References: <CAA69SC5w-0KAGcX_akmhtFJL=mte+3ZrShKPtnWgcML+z-HhKw@mail.gmail.com>
 <CAA69SC7KYFf2wWpPt4L79wmWL-8YvfNhGmMrdRfvYpiJYEzBvA@mail.gmail.com>
 <CALW=WEDWu--TgthZejdbv3QDbJf6T8kmYtg9Th7qMrC9evoB_Q@mail.gmail.com>
 <CABdc3Wp2BwKqAbkzAsu=sX3kAP3+zTjqkxkZ8zO5i-dUNtbDYw@mail.gmail.com>
 <CAA69SC6Q9i1XQ3vy3cGHb49pdf--KVa6tdEXrrDL_Q1dC3PzcA@mail.gmail.com>
 <CABdc3Wp=TwUq8a9uFfMPQ28Cf46mZxzBjM9xtWEko9+jocQF2g@mail.gmail.com>
 <CAA69SC7b8csswSjGYthiR=fmy+vkgoZA9AFsp=+ikFHBh13Wtg@mail.gmail.com>
 <CABdc3Wpbsvw+4Bx9zyrDz55wAKO7PxSK=v+KeP7N9UEiyyqhnA@mail.gmail.com>
 <CAA69SC7h46FXhVovkN3nn1WU3Y=oVmcFMjio5EObZP2M3iHhmA@mail.gmail.com>
 <167d6432-e4d6-d87d-5d31-d3d82a8de4ce@fleshgrinder.com> <CAA69SC52t7n7aSWy4VVUhU9yjtkku3rv1WBCkVwy_N0RxXpEbA@mail.gmail.com>
 <CABdc3WoH8hHgiaRprszRkJWKk8gQijrxMrM95AWh3V3c41Oraw@mail.gmail.com>
 <99F80C06-654D-4109-BE07-2FA5B1073E5D@ez.no> <CAA69SC71Zx4ooS2pNnH+aSR+D1fxxtFA+zfZLKpFVvUh635t1g@mail.gmail.com>
 <4f54308a-4a69-2e6b-2ed0-51d4336d1cd4@fleshgrinder.com> <5969d1af-48e5-1376-07fe-9568de538145@texthtml.net>
 <CABdc3Wp13y2bjC-T3PuiXLvN_3rvenQ3J9f0562+xu4Yij70wg@mail.gmail.com>
Date: Fri, 2 Sep 2016 09:10:17 +0200
Message-ID: <CAA69SC45Qva3-fky+P_Bbq2rw9F5ThJQ7NzbANa2ZpZFXvMOXw@mail.gmail.com>
To: =?UTF-8?Q?Micha=C5=82_Brzuchalski?= <michal@brzuchalski.com>
Cc: Mathieu Rochette <mathieu@texthtml.net>, PHP Internals List <internals@lists.php.net>, 
	Fleshgrinder <php@fleshgrinder.com>
Content-Type: multipart/alternative; boundary=001a1144981ed6a79a053b8105a4
Subject: Re: [PHP-DEV] RFC - Immutable classes
From: marijic.silvio@gmail.com (=?UTF-8?Q?Silvio_Mariji=C4=87?=)

--001a1144981ed6a79a053b8105a4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.

Best,
Silvio.

2016-09-02 4:23 GMT+02:00 Micha=C5=82 Brzuchalski <michal@brzuchalski.com>:

> Firstly, thanks for your interest.
> My answers are inline.
>
> 2016-09-01 23:48 GMT+02:00 Mathieu Rochette <mathieu@texthtml.net>:
>
> >
> >
> > On 09/01/2016 09:12 PM, Fleshgrinder wrote:
> > > On 9/1/2016 3:49 PM, Silvio Mariji=C4=87 wrote:
> > >> 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! :)
> > indeed! nice to see this going forward
> > >
> > > 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.
> > I guess they are not authorized in immutable classes as they are not
> > immutable themselves, but I think it could be explained
> >
>
> Yes that could be explained, they are actually not authorized because we
> cannot guarantee developer will use them internally only. So in case this
> property will interact with immutable object state should be also
> immutable.
>
>
> > >
> > > 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 genera=
te
> > > documentation).
> > agreed, I don't get why it's not possible :/
> > >
> >
>
> I think any RFC enchancements in this area is welcome.
>
>
> > > 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 =3D [];
> > >
> > >     public immutable $value;
> > >
> > >     private function __construct($value) {
> > >       $this->value =3D $value;
> > >     }
> > >
> > >     public static function ENUM_ORD() {
> > >       if (isset(self::$instances[1]) =3D=3D=3D false) {
> > >         self::$instances[1] =3D new self(1);
> > >       }
> > >
> > >       return self::$instances[1];
> > >     }
> > >
> > >   }
> > >
> > >   $o1 =3D Flyweight::ENUM_ORD();
> > >   $o2 =3D Flyweight::ENUM_ORD();
> > >
> > >   var_dump($o1 =3D=3D=3D $o2); // bool(true)
> > I can understand the usecase, but then, how could  the language ensure
> > the class is immutable
>
>
> It cannot be ensured while non-immutable property will exists in immutabl=
e
> object.
>
>
> > side note: what about access (read & write) to undefined properties ?
> >
>
> You mean properties which are declared and default null and never changed
> during object instantiation?
>
>
> > >
> > > 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.
> >
>
> We agreed that it would be best for ensuring the object state is immutabl=
e
> (that implies it can be deeply frozen for writes as deep as all his
> properties
> and properties object properties etc.)
>
>
> > >
> > > 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. (Migh=
t
> > > take a while so bare with me.)
> > >
> >
> > The RFC contains several grammatical issues. I could help you with that
> > > too if you want.
> > >
> >
>
> As abowe any RFC enchancements are welcome :)
>
>
> > > There is a lot of diff noise in the ext/tokenizer/tokenizer_data.c
> file.
> > >
> >
> > --
> > Mathieu Rochette
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
> --
> regards / pozdrawiam,
> --
> Micha=C5=82 Brzuchalski
> brzuchalski.com
>



--=20
Silvio Mariji=C4=87
Software Engineer
2e Systems

--001a1144981ed6a79a053b8105a4--