Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108997 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 66377 invoked from network); 12 Mar 2020 20:56:01 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 12 Mar 2020 20:56:01 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 354FC1804F6 for ; Thu, 12 Mar 2020 12:17:27 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS11403 64.147.123.0/24 X-Spam-Virus: No X-Envelope-From: Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 12 Mar 2020 12:17:26 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 49DD8876 for ; Thu, 12 Mar 2020 15:17:25 -0400 (EDT) Received: from imap26 ([10.202.2.76]) by compute7.internal (MEProxy); Thu, 12 Mar 2020 15:17:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=vSj1hWVCtuZEgrg6tkE4afzZ9lWLFZgb9CkY1eBYE I0=; b=uIQZzFShFtJv/jcuRAn9MAXnlMjM4QJubMjnALREMRRtpaOzgBH9/GKEK iam/rxu6Iqlj/iKic1p5YU3WZetSw9Lk8K1ANRdLdQgPiSEd31aMUVQy1X6yuIVl FHbL+W2wMw7IGb27nMuCL+fG/NqbbiJE9Rk07TUwUx5eSmYawfTfcsfgMXm1PqIC Z3xFgy3PNSKm7glxjG3AiAJrihKIpKwFZ6/H/vJrT19wK7U3plihI5JuxPvX7Mh+ G+JGia4RuMUtPHPW4o8bYxnx2VpwdzeahMTiFGXZsNrbmaekmbi0TTobYFeMvn70 QIS2J+KkYBeJEbH9HzRFWJMDo+NQA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddvhedguddvgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenucfjughrpefofgggkfgjfhffhffv ufgtgfesthhqredtreerjeenucfhrhhomhepfdfnrghrrhihucfirghrfhhivghlugdfuc eolhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtohhmqeenucffohhmrghinhepfehv gehlrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homheplhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5D3DE14200A2; Thu, 12 Mar 2020 15:17:24 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-991-g5a577d3-fmstable-20200305v3 Mime-Version: 1.0 Message-ID: <700327df-45d5-47ca-8828-d7ad9c9bee2e@www.fastmail.com> In-Reply-To: References: <8545d15e-ddd5-42be-8405-09697a077234@www.fastmail.com> <4d9688fe-cc57-44af-903e-05f4cbb1bbcc@www.fastmail.com> <6bcbf0a5-92d8-4cfa-a00f-e0e967fc037e@www.fastmail.com> Date: Thu, 12 Mar 2020 14:17:03 -0500 To: "php internals" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Immutable/final/readonly properties From: larry@garfieldtech.com ("Larry Garfield") On Thu, Mar 12, 2020, at 8:57 AM, M=C3=A1t=C3=A9 Kocsis wrote: > As you might noticed, I've not opened the vote yet. Partly because I w= as > improving > my implementation as well as the RFC itself (added some words about th= e > inheritance > implications), but the main reason is that a question arise in the > meanwhile. >=20 > Namely, "write-once" properties could in principle support covariance.= That > is, a subclass > would be allowed to tighten the property type that is inherited from t= he > parent class. > It would be a slight change compared to regular properties that are > invariant. >=20 > All this would be possible because of the quasi-immutable nature of > "write-once" properties: > they are generally expected to be assigned to only once, in the constr= uctor > - which is exempt from > LSP checks. >=20 > There is a gotcha though... In practice, "write-once" properties could= be > written from places > other than the constructor. Although there might not be many practical= > use-cases for it, > the infamous setter injection is certainly one (as shown at > https://3v4l.org/DQ3To), in which > case property covariance would be a problem. >=20 > That's why I'm curious about some additional input on the matter. Do y= ou > think > covariance of "write-once" properties is worth to have even though the= re > might be > some edge-cases when it can't be supported perfectly? I'll include thi= s > topic a bit later > in the RFC as well. In the worst case it could be added to the "Future= > Scope" section > because - and correct me if I'm wrong - we can also add support for it= > later since it would be > a non-breaking change. >=20 > Cheers, > M=C3=A1t=C3=A9 I'd strongly suggest not messing with that for now. There's a definite = can of worms, not all of which we likely know about yet. Plus, as you s= ay, it's easier to add support for that later if we can find all of the = worms than to try and put those worms back in the box after they've gott= en loose. --Larry Garfield