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é Rømcke <andre.rom...@ez.no>: > > > > On Sep 2, 2016, at 09:10 , Silvio Marijić <marijic.sil...@gmail.com> > 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 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. > > > _If_ there are use-cases for it, wouldn’t it also be safe that the clone > is allowed to be modified during __clone() and afterwards sealed? Like in > __construct(). > And if you don’t want to allow cloning, throw in __clone. > > Best, > André > > > > > > Best, > > Silvio. > > > > 2016-09-02 4:23 GMT+02:00 Michał Brzuchalski <mic...@brzuchalski.com>: > > > >> Firstly, thanks for your interest. > >> My answers are inline. > >> > >> 2016-09-01 23:48 GMT+02:00 Mathieu Rochette <math...@texthtml.net>: > >> > >>> > >>> > >>> On 09/01/2016 09:12 PM, Fleshgrinder wrote: > >>>> On 9/1/2016 3:49 PM, Silvio Marijić 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 class > >>>> might want to contain an internal cache (e.g. flyweight pattern). > >>>> > >>>> immutable final class Flyweight { > >>>> > >>>> private static $instances = []; > >>>> > >>>> public immutable $value; > >>>> > >>>> private function __construct($value) { > >>>> $this->value = $value; > >>>> } > >>>> > >>>> public static function ENUM_ORD() { > >>>> if (isset(self::$instances[1]) === false) { > >>>> self::$instances[1] = new self(1); > >>>> } > >>>> > >>>> return self::$instances[1]; > >>>> } > >>>> > >>>> } > >>>> > >>>> $o1 = Flyweight::ENUM_ORD(); > >>>> $o2 = Flyweight::ENUM_ORD(); > >>>> > >>>> var_dump($o1 === $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 > 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 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 > 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. (Might > >>>> 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ł Brzuchalski > >> brzuchalski.com > >> > > > > > > > > -- > > Silvio Marijić > > Software Engineer > > 2e Systems > > -- Silvio Marijić Software Engineer 2e Systems
