Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108717 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 30554 invoked from network); 22 Feb 2020 02:27:12 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 22 Feb 2020 02:27:12 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8F1A4180088 for ; Fri, 21 Feb 2020 16:43:42 -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.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_NONE 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-qk1-f178.google.com (mail-qk1-f178.google.com [209.85.222.178]) (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 ; Fri, 21 Feb 2020 16:43:40 -0800 (PST) Received: by mail-qk1-f178.google.com with SMTP id d11so3601874qko.8 for ; Fri, 21 Feb 2020 16:43:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dqxtech-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g6Op0BYC2K0LH52Jm+WJSmh5zuXqb44QNQRL7kNnGsE=; b=HiOXbGa3pPoENYZiw2mqmZd5buJaZ4sxrzGr5CKCljCUBEgs92g9K5z+6PanFk691l 51wFEa3ms9UlkcRb5UdF6i/6Z77K6Je7XHwMyiU9TApJhTtgIxNdTQRRVKkvMyh1TpRO tH0+YdQemRf9Wy8E2dYix965HZ0/fJFIh5zzTNlxXmXtySa29lsk6JNVaQbgxLFHGmrs wJ2nt4vuRxCV9bBtUZo6eOGdTSKFKgW7CGu/kcGimTZcrmRJMsGWXzOUj735Kh89qLGc H5zlwiOr8XYKdJy/SB3aVjBKmbGMXccnj6g4qWZ/oIwxLObfO4/hrEd+xHwYs6O+v3gG etyA== 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=g6Op0BYC2K0LH52Jm+WJSmh5zuXqb44QNQRL7kNnGsE=; b=PSRjzWaI/J+mBrB7zZ2EfvAFt/n1q4EVImiaoawdfkyJAWtQn8zOXhuqxNwPKis5zo TeR5GXD46jV/PhEH9hXGEcue6T5HSItqOVc4Uuwpj8dofx1PLazEptxfrGwQUoVepL2D aJGv4XbZM2RqzioR8IAfUKcHZ5DcJzutoLD/w+MKo3AxbPAL3AeocxXT+185SdbLLOb7 mTBtl5mpbmaA8/gilbcRy39jOYDqdIY2W2bppSe58+vfZSQg4HoiOfbDK4nJ+Kcl1P0C lZAztePPGiiHjWdzD9W7PfO8QxRg14o4oQ7FUhQ8Vtl1euwn4rnP0CcgetspHUwgXmsB WlDg== X-Gm-Message-State: APjAAAWAewMR03aeJB+UOGlT1z6k8OxnN/3Ozwtli2+y3XswMPmVkCGP 0OhBqZb6Oe5aCPdqKXtam9YkUQjXLqw= X-Google-Smtp-Source: APXvYqw4f6HRoq08LHexE18qKO13qwj8yEaci7sD0MjiQvMIwTiruTcLMCe2halT21LOQ462GBPAVA== X-Received: by 2002:a37:6c9:: with SMTP id 192mr310719qkg.25.1582332219491; Fri, 21 Feb 2020 16:43:39 -0800 (PST) Received: from mail-qv1-f49.google.com (mail-qv1-f49.google.com. [209.85.219.49]) by smtp.googlemail.com with ESMTPSA id r1sm2337132qtu.83.2020.02.21.16.43.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Feb 2020 16:43:38 -0800 (PST) Received: by mail-qv1-f49.google.com with SMTP id ci20so444399qvb.4 for ; Fri, 21 Feb 2020 16:43:38 -0800 (PST) X-Received: by 2002:ad4:58ef:: with SMTP id di15mr17293751qvb.123.1582332218023; Fri, 21 Feb 2020 16:43:38 -0800 (PST) MIME-Version: 1.0 References: <8545d15e-ddd5-42be-8405-09697a077234@www.fastmail.com> <4d9688fe-cc57-44af-903e-05f4cbb1bbcc@www.fastmail.com> In-Reply-To: <4d9688fe-cc57-44af-903e-05f4cbb1bbcc@www.fastmail.com> Date: Sat, 22 Feb 2020 01:43:25 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="000000000000c5a66a059f1f6d6e" Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Immutable/final/readonly properties From: andreas@dqxtech.net (Andreas Hennings) --000000000000c5a66a059f1f6d6e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable When writing immutable classes, I want to be able to set properties in static factories and in wither methods. Once the new instance is sent to the outside world, its properties can be locked to prevent further modification. This sounds to me like we need different modes. Either the object itself would have different states over time, or the object stays the same and instead some methods have mutation permission on newly created objects. This could be seen as a runtime state problem or as a compile time code verification problem. On Sat, 22 Feb 2020, 00:18 Larry Garfield, wrote: > On Fri, Feb 21, 2020, at 4:29 AM, M=C3=A1t=C3=A9 Kocsis wrote: > > > > > > Yeah, I'm definitely thinking in relation to the earlier discussion, > since > > > I think they're all inter-related. (This, property accessors, and > constant > > > expressions.) > > > > > > > The biggest question is whether it's worth to support both readonly > > properties and property accessors. My answer is clear yes, because ther= e > > are many-many > > ways to mess with private or protected properties without and public > > setters from the outside - in which case property accessors couldn't he= lp > > much. I collected some examples I know of: > > https://3v4l.org/Ta4PM > > I didn't even know you could do some of those. That's horrifying. :-) > > > > As Nikita notes above, a read-only property with a default value is..= . > > > basically a constant already. So that's not really useful. > > > > I agree that they are not very useful, however I wouldn't restrict thei= r > > usage. Mainly because there are probably some legitimate use-cases, but= I > > also think it would > > be advantageous to be consistent with the other languages in this case. > > If they could do something that class constants can't, that would make > them useful. If not, then I feel like it would just be introducing new > syntax for the same thing, without much benefit. (I'm thinking of, eg, > could you set them by default to a new Foo() object, which you could then > modify the Foo but not change it for another object, thus moving that > initialization out of the constructor? That sort of thing.) > > > > If we could address the performance impact, that would give us much > more > > > functionality-for-the-buck, including an equivalent of read-only > properties > > > including potentially lazy initialization. Or derive-on-demand > behavior > > > would also be a big increase in functionality. > > > > > > It's not that I don't see a value to this RFC; I actually have a few > > > places in my own code where I could use it. It's that I see it as > being of > > > fairly narrow use, so I'm trying to figure out how to increase it so > that > > > the net-win is worth it. > > > > > > > The reason why I brought up this RFC is that I'd really like to add > > first-class support for immutable objects, and it seemed to be a good > idea > > to first go for readonly properties. > > This way, the scope of an immutable object RFC gets smaller, while it's > > possible to only have readonly properties alone. > > > > Regards, > > M=C3=A1t=C3=A9 > > I'm totally on board for better value object support, so that's a good > motive for me. The question I have is whether this is really a good > stepping stone in that direction or if it would lead down a wrong path an= d > lock us into too much TIMTOWTDI (for the Perl fans in the room). So let'= s > think that through down that path. How would write-once properties lead > into properly immutable value objects? Or do they give us that themselve= s? > > The biggest challenge for immutable objects, IMO, is evolving them. Eg, > $result->withContentType(...) to use the PSR-7 example. Would we expect > people to do it with a method like that, or would there be some other > mechanism? If the properties are public, would we offer a more syntactic > way to modify them directly? > > The with*() method style requires cloning the object. What happens to th= e > locked status of a set property if the object is cloned? Are they then > settable again, or do they come pre-locked? > > Neither of those seem good, now that I think about it. If they come > pre-locked, then you really can't clone, change one property, and return > the new one (as is the standard practice now in that case). If they don'= t > come pre-locked, then the newly created object can have everything on it > changed, once, which creates a loophole. I'm not sure what the right > answer is here. > > My other concern is a public property (the most likely use case) would > have to be set in the constructor. If it's not, then callers cannot rely > on it having been set yet if it's set lazily. And if code inside the cla= ss > tries to set it lazily, it may already have been set by some external cod= e > (rightly or wrongly) and cause a failure. > > How do we address that? There's absolutely use cases where setting > everything in the constructor ahead of time is what you'd do anyway, but > there are plenty where you wouldn't want to, either, which creates a race > condition for who sets it first, or tries to access it before it gets set= , > etc. (This is where my repeated questions about lazy initialization come > from.) > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --000000000000c5a66a059f1f6d6e--