thank you for the clarification, more questions inline :)
On 09/02/2016 04:23 AM, Michał Brzuchalski wrote: > 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? I meant properties which are not declared at all, eg: class foo { } $f = new foo(); var_dump($f->bar); $f->bar = 'taz'; I expect it to print null and throw an error on write access, but it's just to be sure. actually I guest it should be the same than with declared with 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 >> >> > -- Mathieu Rochette -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
