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ł 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
