Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:95549 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 90746 invoked from network); 2 Sep 2016 02:23:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Sep 2016 02:23:47 -0000 Authentication-Results: pb1.pair.com smtp.mail=michal@brzuchalski.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=michal@brzuchalski.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain brzuchalski.com designates 188.165.245.118 as permitted sender) X-PHP-List-Original-Sender: michal@brzuchalski.com X-Host-Fingerprint: 188.165.245.118 ns220893.ip-188-165-245.eu Received: from [188.165.245.118] ([188.165.245.118:35641] helo=poczta.brzuchalski.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 21/89-47600-FA2E8C75 for ; Thu, 01 Sep 2016 22:23:44 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by poczta.brzuchalski.com (Postfix) with ESMTP id 9962F298423C for ; Fri, 2 Sep 2016 04:23:40 +0200 (CEST) Received: from poczta.brzuchalski.com ([127.0.0.1]) by localhost (poczta.brzuchalski.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDQHvzAyTdU7 for ; Fri, 2 Sep 2016 04:23:36 +0200 (CEST) Received: from mail-qt0-f174.google.com (unknown [209.85.216.174]) by poczta.brzuchalski.com (Postfix) with ESMTPSA id 0BA3B298423A for ; Fri, 2 Sep 2016 04:23:34 +0200 (CEST) Received: by mail-qt0-f174.google.com with SMTP id 93so51943367qtg.2 for ; Thu, 01 Sep 2016 19:23:34 -0700 (PDT) X-Gm-Message-State: AE9vXwP1WjXaDbm/iUmNK06BEqMnbiA0AazTwQEMIhpwzKKVKolHJHYg1NGEU737bYadE41NlRuI0+1xooc4lg== X-Received: by 10.237.46.6 with SMTP id j6mr21679282qtd.113.1472783013287; Thu, 01 Sep 2016 19:23:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.56.99 with HTTP; Thu, 1 Sep 2016 19:23:32 -0700 (PDT) In-Reply-To: <5969d1af-48e5-1376-07fe-9568de538145@texthtml.net> References: <167d6432-e4d6-d87d-5d31-d3d82a8de4ce@fleshgrinder.com> <99F80C06-654D-4109-BE07-2FA5B1073E5D@ez.no> <4f54308a-4a69-2e6b-2ed0-51d4336d1cd4@fleshgrinder.com> <5969d1af-48e5-1376-07fe-9568de538145@texthtml.net> Date: Fri, 2 Sep 2016 04:23:32 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Mathieu Rochette Cc: PHP Internals List , Fleshgrinder Content-Type: multipart/alternative; boundary=94eb2c12400056a1e1053b7d043c Subject: Re: [PHP-DEV] RFC - Immutable classes From: michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=) --94eb2c12400056a1e1053b7d043c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Firstly, thanks for your interest. My answers are inline. 2016-09-01 23:48 GMT+02:00 Mathieu Rochette : > > > On 09/01/2016 09:12 PM, Fleshgrinder wrote: > > On 9/1/2016 3:49 PM, Silvio Mariji=C4=87 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 th= e > > 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 tak= e > > objects must be immutable too? It's clear why an immutable property mus= t > > 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 =3D []; > > > > public immutable $value; > > > > private function __construct($value) { > > $this->value =3D $value; > > } > > > > public static function ENUM_ORD() { > > if (isset(self::$instances[1]) =3D=3D=3D false) { > > self::$instances[1] =3D new self(1); > > } > > > > return self::$instances[1]; > > } > > > > } > > > > $o1 =3D Flyweight::ENUM_ORD(); > > $o2 =3D Flyweight::ENUM_ORD(); > > > > var_dump($o1 =3D=3D=3D $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 no= t > > 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 an= d > > 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 > > --=20 regards / pozdrawiam, -- Micha=C5=82 Brzuchalski brzuchalski.com --94eb2c12400056a1e1053b7d043c--