Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95554
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain texthtml.net designates 62.210.206.189 as permitted sender)
To: =?UTF-8?Q?Micha=c5=82_Brzuchalski?= <michal@brzuchalski.com>
References: <CAA69SC5w-0KAGcX_akmhtFJL=mte+3ZrShKPtnWgcML+z-HhKw@mail.gmail.com>
 <CABdc3Wp2BwKqAbkzAsu=sX3kAP3+zTjqkxkZ8zO5i-dUNtbDYw@mail.gmail.com>
 <CAA69SC6Q9i1XQ3vy3cGHb49pdf--KVa6tdEXrrDL_Q1dC3PzcA@mail.gmail.com>
 <CABdc3Wp=TwUq8a9uFfMPQ28Cf46mZxzBjM9xtWEko9+jocQF2g@mail.gmail.com>
 <CAA69SC7b8csswSjGYthiR=fmy+vkgoZA9AFsp=+ikFHBh13Wtg@mail.gmail.com>
 <CABdc3Wpbsvw+4Bx9zyrDz55wAKO7PxSK=v+KeP7N9UEiyyqhnA@mail.gmail.com>
 <CAA69SC7h46FXhVovkN3nn1WU3Y=oVmcFMjio5EObZP2M3iHhmA@mail.gmail.com>
 <167d6432-e4d6-d87d-5d31-d3d82a8de4ce@fleshgrinder.com>
 <CAA69SC52t7n7aSWy4VVUhU9yjtkku3rv1WBCkVwy_N0RxXpEbA@mail.gmail.com>
 <CABdc3WoH8hHgiaRprszRkJWKk8gQijrxMrM95AWh3V3c41Oraw@mail.gmail.com>
 <99F80C06-654D-4109-BE07-2FA5B1073E5D@ez.no>
 <CAA69SC71Zx4ooS2pNnH+aSR+D1fxxtFA+zfZLKpFVvUh635t1g@mail.gmail.com>
 <4f54308a-4a69-2e6b-2ed0-51d4336d1cd4@fleshgrinder.com>
 <5969d1af-48e5-1376-07fe-9568de538145@texthtml.net>
 <CABdc3Wp13y2bjC-T3PuiXLvN_3rvenQ3J9f0562+xu4Yij70wg@mail.gmail.com>
Cc: PHP Internals List <internals@lists.php.net>,
 Fleshgrinder <php@fleshgrinder.com>
Message-ID: <7b45006f-7b02-3863-9bb3-bc911863c8ab@texthtml.net>
Date: Fri, 2 Sep 2016 11:06:01 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101
 Thunderbird/50.0a2
MIME-Version: 1.0
In-Reply-To: <CABdc3Wp13y2bjC-T3PuiXLvN_3rvenQ3J9f0562+xu4Yij70wg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Subject: Re: [PHP-DEV] RFC - Immutable classes
From: mathieu@texthtml.net (Mathieu Rochette)

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