Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115369 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 76187 invoked from network); 8 Jul 2021 12:56:59 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 8 Jul 2021 12:56:59 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 22C7B1804B0 for ; Thu, 8 Jul 2021 06:19:15 -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,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 ; Thu, 8 Jul 2021 06:19:14 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 108D65C00C6 for ; Thu, 8 Jul 2021 09:19:14 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute1.internal (MEProxy); Thu, 08 Jul 2021 09:19:14 -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=fm3; bh=aI+RXMMhJflNFXjYluqQDfJqYRvKzDicAxt2C0IUz rU=; b=LnZVsvxaRwMtkOu5JDMxoHrLNw0slkh37mZn5AIv7DNqtv6beTLHVt5a8 uGbtJ3+RJU7+V9B7pKDi1Uqsh43sj+t7+O6MTN3k5IKX+s8m/+yH765iQxtSzrEh o0J1w7OfLfHFgFgG6Y40rcQw8BiTtDlnupkMmwOZ3wcgzt8emez02nnDRxs2rktx 9AF/4UcJelZ6TdrcHFeCtk9wmVrzEJzhhmeM002G2XZ3aMmL6wrp7rEx4BQJ1pBH esV4sqkkkdeaQzN++QskBhgTsdCt+FpCagoxhYjQSbTY9Yz7OQ5Yn+qJgjZBkbMN CJuyftJBd5qP4ci5aOkO6FTUXsbEA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrtdeggdeivdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdfnrghr rhihucfirghrfhhivghlugdfuceolhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtoh hmqeenucggtffrrghtthgvrhhnpeffffffjeffudfggeevvdeitdetvdfgjefffeffjeel feejteevheeghffhvdfgleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 752B5AC0082; Thu, 8 Jul 2021 09:19:13 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-531-g1160beca77-fm-20210705.001-g1160beca Mime-Version: 1.0 Message-ID: In-Reply-To: <6E3E4594-398B-4219-8B79-7863F54BCD32@stitcher.io> References: <0a035a3f-60ef-4001-8c55-f26ab518c3d5@www.fastmail.com> <6E3E4594-398B-4219-8B79-7863F54BCD32@stitcher.io> Date: Thu, 08 Jul 2021 08:18:52 -0500 To: "php internals" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Readonly properties and interfaces From: larry@garfieldtech.com ("Larry Garfield") On Wed, Jul 7, 2021, at 10:33 PM, Brent Roose wrote: > > The property accessor RFC (which didn't get to a vote) discussed thi= s, and specifically proposed making properties part of the interface for= ... basically all the reasons given here. > >=20 >=20 > I thought the RFC didn't go to vote because Nikita didn't feel like it= =20 > warranted the complexity: >=20 > > This RFC overlaps with the Property Accessors RFC. In particular, it= implements the =E2=80=9Conly implicit get=E2=80=9D aspect, though not w= ith the exact same semantics. As mentioned in the RFC, I'm not convinced= that the full complexity of accessors is truly warranted. Supporting re= adonly properties and asymmetric visibility would cover a significant po= rtion of the use-cases, at a lower language complexity cost. [1] >=20 > Is there any reason to assume property accessors will be reconsidered = for 8.2?=20 Nothing is guaranteed. :-) However, Nikita said very clearly in the rea= donly discussion that he doesn't see it as precluding the asymmetric vis= ibility portion of accessors, which is still simpler than full on explic= it accessor methods. We "just" have to convince Nikita that upgrading r= eadonly to asymmetric visibility in 8.2 (with or without explicit method= s) is justified, and that it should include the interface portion of tha= t, too. --Larry Garfield