Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108596 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 34770 invoked from network); 15 Feb 2020 16:10:04 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 15 Feb 2020 16:10:04 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id E37FF1804AB for ; Sat, 15 Feb 2020 06:24:58 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 15 Feb 2020 06:24:58 -0800 (PST) Received: by mail-vs1-f46.google.com with SMTP id x123so8055125vsc.2 for ; Sat, 15 Feb 2020 06:24:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nbp5fuobC9f8ijt+VC23BW+VgLPaX8fhafhAXAvsQXg=; b=ZtcphUehekIRBF+lKPAagRxysR63jASd64G79K8nx9lhTA4+hTnl4bksVjiY6+AMqx cBYmwhkHHqiKni7HjlFceKNMSTLsQqrDgVDqWT+YGVqWfCgXfE8cTcuM5XpNzLOjrBCw +9BBgRW9wwDDo+QL/piikt6LtHfYafzMPGU5jE2Sj2781sZlHTuzgvlkBl2jh279+PP3 vHX8ZgdnwkUX+g4Idv6jHidWXUJJvUagQRViucXoELENMC3dCs8rJpZ9e6dJUECKWo29 A/gaeEbcAJmL7+61rnvnq1klOgK13SLu4zZd/kXD9oed5FK8UxzVP2pieD+QdWYvlZd9 Bv/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nbp5fuobC9f8ijt+VC23BW+VgLPaX8fhafhAXAvsQXg=; b=kmo8wbmNAdOdCLOUKUoLCxU0MUmNpll/9uAJQTGMfzOuGHQC+fEilhP6v6WejJB0YI DRlH0CXutZ4jv5A2rE+RKzmWPK38GIXqrzVujKqB17WOGzEk6qrCjXIB9rVgTQcLuceB rYkbyv3S74ZdvJ3nv3f2c0UMn9s428C8iZJCvV2YsBXXdx6rL77ZQPouz7J8fqKc7t1p 4livhcgJRjlW2cQ2ec1fe0phU9WpPOqYBij9d4haddHjJsCl4l4wbb4KMS8S+pPrGAB8 jQ25wgESwV+3szwlV5QCNy0wW3Ku/lyroPkBKSk85JiTrWkDMuA4uEZYNME+NbQBZA5Y U6DA== X-Gm-Message-State: APjAAAWuQmGkwvG6DmTe7cnbSIjZcVpeJTH7pQKxG07ww011IS3ej7HV IcP6+kGSWxNABvNR5LYyePuyl8AD3f5leD5h32s= X-Google-Smtp-Source: APXvYqwaHDAC1cgq1EN9mxW95bzrlyvBfoGb5NyG+N6OoQKuhFaf5hMUO/rKBPILoajpDOKZHomCpECpKMd0PwuTgeE= X-Received: by 2002:a05:6102:757:: with SMTP id v23mr4112512vsg.35.1581776695298; Sat, 15 Feb 2020 06:24:55 -0800 (PST) MIME-Version: 1.0 References: <60cc7417-837d-4ca2-8661-e32b255ef2db@www.fastmail.com> In-Reply-To: <60cc7417-837d-4ca2-8661-e32b255ef2db@www.fastmail.com> Date: Sat, 15 Feb 2020 15:24:44 +0100 Message-ID: To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="000000000000098d50059e9e1624" Subject: Re: [PHP-DEV] [RFC] [PROPOSAL] Immutable/final/readonly properties From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=) --000000000000098d50059e9e1624 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Larry, I admit that this flag is not too interesting, but I believe it still has its own merit. I can imagine that the flag could play well with property accessors as well, however, in my opinion, the main use-case of final properties generally doesn't involve setters/set accessors. > In that case, "final" or "lazy" or "locked" would be reasonable names; read-only and immutable are misleading, as it's really write-once, not read-only, not truly immutable. In the meanwhile, I realized that - "immutable" is simply not true in case of resource and (non-immutable) object properties - "readonly" is probably somewhat better, but still not always true in case of lazy initialization - "final" seems ok, but it would probably be a better fit for a feature that would prevent a property to be overwritten (similarly to "final" for methods) So I think "final" should only be chosen if we don't want to restrict property overwriting later. Otherwise, we could use also "locked" or "sealed" (inspiring from C#). > As for references and untyped final properties... Just don't go there. Require a final property to be non-reference and typed. So it's essentially what Marco also suggested... Unfortunately, I didn't exactly get the idea first (I focused too much on the mixed type), but restricting final to typed properties now seems reasonable. :) But let me collect the possibilities that I've thought about so far: - do not implicitly initialize untyped final properties: although I liked this idea first, now it feels a bit unintuitive - add support for mixed, and implicitly convert untyped final properties to this type: unintuitive - require final properties to be explicitly initialized before object instantiation finishes: complicated, makes lazy initalization/proxying difficult/impossible - require final properties to be typed: looks straightforward > I do not foresee untyped properties ever going away Although I tend to declare types everywhere I can, I also believe we should leave gradual typing intact. Thank you very much for the feedback! M=C3=A1t=C3=A9 Kocsis Larry Garfield ezt =C3=ADrta (id=C5=91pont: 2020. = febr. 15., Szo, 9:18): > On Fri, Feb 14, 2020, at 7:22 AM, M=C3=A1t=C3=A9 Kocsis wrote: > > Hi Internals, > > > > I'd like to propose the idea of adding support for > immutable/final/readonly > > properties in PHP 8. > > > > My plan is to add a new immutable/final/readonly (the name is up for > > debate) property modifier to the language so that these kind of > properties > > could only be initialized but not modified afterwards. Unlike how final > > properties in Java work, I think it would be beneficial to allow lazy > > initialization of these properties after object construction have taken > > place. Currently, I'm in favour of using final or readonly, but not yet > > very sure. > > > > I'll write a proper RFC in the following days/week. My clear intent wit= h > > final properties is to pave the road for immutable objects for which I > have > > a POC pull request open (but I haven't pushed all my work yet). > > > > So far, my biggest question (apart from the name) have been how non-typ= ed > > properties should behave: as they are implicitly initialized to null if > > they don't have an explicit default value (while typed properties remai= n > > uninitialized), further modifications would be impossible to do on them= - > > which would make non-typed final properties almost useless. Nikita > > suggested to just avoid their initialization, but I'd be curious about > > other ideas as well. > > > > Thanks, > > M=C3=A1t=C3=A9 Kocsis > > My concern is that a simple read-only/final "flag" is a very limited > feature set. I'd still love for us to revisit property accessors at some > point (if the performance issues could be resolved), and I fear that > layering that *and* a read-only flag together would result in... much > complex weirdness. (Technical term.) > > That said, were such a feature to be added, I would strongly recommend > making them able to be defined in terms of an expression, or possibly a > callable/anon function, with no explicit setting allowed. To wit: > > class Foo { > > protected string $firstName; > protected string $lastName; > > protected function getFullName() { return $this->firstName . > $this->lastName; } > > // And then one of these options: > > public final string $fullName =3D $this->firstName . $this->lastName; > > public final string $fullName =3D fn() =3D> $this->firstName . > $this->lastName; > > public final string $fullName =3D $this->getFullName(); > } > > That would allow for their complete definition in one location, make it > clear how they're derived, etc. They essentially become an auto-memoizin= g > method (which suits me just fine). Their value would potentially change > depending on when it's first called depending on the other values in the > object, but that's no different than if they were simply "set" from an > arbitrary location. The potential for unpredictable semi-non-determinism > is the same, or possibly better this way. > > (In that case, "final" or "lazy" or "locked" would be reasonable names; > read-only and immutable are misleading, as it's really write-once, not > read-only, not truly immutable. I suppose then an "immutable object" wou= ld > be one in which all properties are either final/lazy/locked or set by the > constructor only.) > > There was a thread a few weeks ago on "lazily derived constants" that > probably has some interesting thoughts as well, though of course this wou= ld > be property-like syntax, which is fine. > > As for references and untyped final properties... Just don't go there. > Require a final property to be non-reference and typed. I do not foresee > untyped properties ever going away (too much legacy code, plus they are > legit useful at times), but that doesn't mean every conceivable property > variant ever needs to support them. Requiring that a final property be > typed non-reference seems entirely reasonable to me. > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --000000000000098d50059e9e1624--