Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95564
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <A722888E-EB21-4467-A5C0-3201A6773E1D@ez.no>
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>
 <CAA69SC45Qva3-fky+P_Bbq2rw9F5ThJQ7NzbANa2ZpZFXvMOXw@mail.gmail.com> <A722888E-EB21-4467-A5C0-3201A6773E1D@ez.no>
Date: Fri, 2 Sep 2016 16:06:04 +0200
Message-ID: <CAA69SC48nvQ9n6h088LsQ=zzo-z07fH31MQKzh9k5TFh7KGLKw@mail.gmail.com>
To: =?UTF-8?B?QW5kcsOpIFLDuG1ja2U=?= <andre.romcke@ez.no>
Cc: =?UTF-8?Q?Micha=C5=82_Brzuchalski?= <michal@brzuchalski.com>, 
	Mathieu Rochette <mathieu@texthtml.net>, PHP Internals List <internals@lists.php.net>, 
	Fleshgrinder <php@fleshgrinder.com>
Content-Type: multipart/alternative; boundary=001a1144981ec6848d053b86d437
Subject: Re: [PHP-DEV] RFC - Immutable classes
From: marijic.silvio@gmail.com (=?UTF-8?Q?Silvio_Mariji=C4=87?=)

--001a1144981ec6848d053b86d437
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=C3=A9 R=C3=B8mcke <andre.romcke@ez.no>:

>
>
> > On Sep 2, 2016, at 09:10 , Silvio Mariji=C4=87 <marijic.silvio@gmail.co=
m>
> 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 abo=
ut
> > 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 clonin=
g,
> > it is disabled for immutable objects, because you'll end up with the co=
py
> > 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=E2=80=99t it also be safe that th=
e clone
> is allowed to be modified during __clone() and afterwards sealed? Like in
> __construct().
> And if you don=E2=80=99t want to allow cloning, throw in __clone.
>
> Best,
> Andr=C3=A9
>
>
> >
> > Best,
> > Silvio.
> >
> > 2016-09-02 4:23 GMT+02:00 Micha=C5=82 Brzuchalski <michal@brzuchalski.c=
om>:
> >
> >> 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
> generate
> >>>> 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 clas=
s
> >>>> 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 ensur=
e
> >>> the class is immutable
> >>
> >>
> >> It cannot be ensured while non-immutable property will exists in
> immutable
> >> 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 propertie=
s
> >>>> and I see use cases where the developer wants more control.
> >>>
> >>
> >> We agreed that it would be best for ensuring the object state is
> immutable
> >> (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. (Mig=
ht
> >>>> take a while so bare with me.)
> >>>>
> >>>
> >>> The RFC contains several grammatical issues. I could help you with th=
at
> >>>> 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
> >>
> >
> >
> >
> > --
> > Silvio Mariji=C4=87
> > Software Engineer
> > 2e Systems
>
>


--=20
Silvio Mariji=C4=87
Software Engineer
2e Systems

--001a1144981ec6848d053b86d437--