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
