>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 <math...@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 <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 > > -- Silvio Marijić Software Engineer 2e Systems
