Re: RFC - Immutable classes

From point of immutability of object, there is no difference if property is defined or not, so you are correct, last line in your code will throw an error. 2016-09-02 11:06 GMT+02:00 Mathieu Rochette <mathieu@texthtml.net>: > 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 <mathieu@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 > > -- Silvio Marijić Software Engineer 2e Systems