Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118359 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 50281 invoked from network); 5 Aug 2022 18:04:08 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 5 Aug 2022 18:04:08 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id CC3421804BC for ; Fri, 5 Aug 2022 13:04:43 -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.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE 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-ej1-f51.google.com (mail-ej1-f51.google.com [209.85.218.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 5 Aug 2022 13:04:43 -0700 (PDT) Received: by mail-ej1-f51.google.com with SMTP id gk3so6778638ejb.8 for ; Fri, 05 Aug 2022 13:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mGr+AqGZkj0LHCzT6CINh/OLj/lUHa43sTo8gvYRg/8=; b=Xtum1RrA9IPv/WpxwTBOTGrjAHB1ePxlZZbyPTIxbAoJEMRt8jqDksYpRQ96xJb73i TKCHZZGPObTcmY38DZ7RwOubcXdlWPulDq+Z6SPfCX9YkxgVWPvRJQoM6rX8RaOVarch 3otlTa0UNJY7ol2AxLNhgnIbH6MdIza1ZGQZSSZak9a39bvzX35/Zw/xBJUPizxp5D3l /FT3Rr2jnVYCquakvQ66Fkj/bRu48g7yNnJ8ZUFxj8QMQL1qa/AVKJ3M3XLGQ8GRgyIJ gBMyfRYUy7Vs9s5Nrlt9dBA2LcBgnG5GfUlo2caDdIK04lwAaKOENoiS/7AhPjemKhlH k9+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mGr+AqGZkj0LHCzT6CINh/OLj/lUHa43sTo8gvYRg/8=; b=v2Li8zb/S9+o2HTS87fdujgb0oLGsbNy9IPiLTSxdvUiPTxy+0jxyFX5mSE8LQbHhg YOeRSOjb5fEklyN8e3OasSIiHpe7OS9GDX6E1s15IJzYWBdhyaFymQpOH8HuhKLkMSvC zLrWH/pmwavxvJXTEIMnF608bxwTY9VLPH2W3gJQuV6MhRotaPKuv1S6Fg4adI4m7xwl lcWn9obFAjBjrcNHQuH3Rvbgfra2pCLzrg0ASmGj7J7qVVKdVa0GYaHwn3rf4dhIvFfE zL1UGktlsDqQxizbLSFG0n3NKIQ9YObl19UURKMS2h7GiDwb8wfUAhIC1R8E+5gyYvpy vFsw== X-Gm-Message-State: ACgBeo0eUraR4sRekulXkwdiyDnb6bJFMpv6wDIASpgCL902ZkGXkOZc GpTVCx1FS6qHt8VVB+xuCHbNXHIl1lZ2s4WTRKMzuspL X-Google-Smtp-Source: AA6agR7Ik/+MLd+H+wSYrp/9mxWF7NM+SuB1aPiweWfl1HfR5MlmhkMBxjp/qEzRr3xhJHHtc1liei9vcDlDe0S6p7w= X-Received: by 2002:a17:906:5d0b:b0:72f:b107:c09f with SMTP id g11-20020a1709065d0b00b0072fb107c09fmr6255322ejt.639.1659729882051; Fri, 05 Aug 2022 13:04:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 5 Aug 2022 21:04:34 +0100 Message-ID: To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="0000000000000af94705e583fa99" Subject: Re: [PHP-DEV] [RFC] Asymmetric visibility From: dragoonis@gmail.com (Paul Dragoonis) --0000000000000af94705e583fa99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 5 Aug 2022, 20:53 Larry Garfield, wrote: > On Fri, Aug 5, 2022, at 2:27 PM, Micha=C5=82 Marcin Brzuchalski wrote: > > Hi Larry, > > > > pt., 5 sie 2022, 19:09 u=C5=BCytkownik Larry Garfield > > > napisa=C5=82: > > > >> Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3: > >> Asymmetric Visibility. > >> > >> https://wiki.php.net/rfc/asymmetric-visibility > >> > >> Details are in the RFC, but it's largely a copy of Swift's support for > the > >> same. > >> > > > > Thanks for taking efforts on new RFC. > > > > Why not C# style property accessors? It feels more natural for me while > > Swift solution IMHO looks weird/odd composed with PHP class definition > > syntax. The arguments in favor from the RFC look forcibly (couldn't fin= d > > better word). > > > > Cheers, > > Micha=C5=82 Marcin Brzuchalski > > There's a couple of reasons. Ilija and I have spent quite a bit of time > brainstorming through accessors, and there's still a lot to finalize ther= e, > and lots of bikeshed potential. It's a non-simple problem space. Howeve= r, > asymmetric visibility is a good stand-alone concept that can work without > accessors, and has ample benefits of its own without accessors, and has f= ar > less bikeshed potential. (There's minor debates that might be had over > syntax, but the behavior is fairly "it is or it isn't".) > > So the primary reason is that this syntax allows us to have asymmetric > visibility without having to think about accessors. We can then, at some > point in the future, have a different discussion about accessors and not > have to worry about asymmetric visibility in the process. The C# syntax = by > nature only works if they come together in the same RFC, or at least one > RFC is built such that it locks in some decisions for the other RFC. > > As an example, one thing we've been discussing is if accessors should be > inline with the property (a la Swift and C#) or annotated methods (as in > Javascript and Python). There's good arguments for both approaches, as > well as good arguments against. But those would have *extremely* differe= nt > implications for how we represent asymmetric visibility. So if we took t= he > C# style for asymmetric visibility, that would realistically lock us into > C# style accessors even before we've had the discussion about if we want > that or not. That's not good. > > (Please don't anyone try to debate which accessor approach to take here; > the whole point is we want to introduce asymmetric visibility without > having that debate yet. We'll be able to have it in the future, I'm sure= . > There's other knock-on effects as well that I'm skipping for now as not > relevant.) > > Keeping them separate also makes extending visibility rules in different > directions (as noted in the Future Scope section) at some point in the > future can also be done without bumping into accessors. Whether or not > those directions are useful is a topic for another time, but it again > allows us to discuss those (like a "once" operation or a "package" scope, > etc.) without worrying about the impact on accessors. > > Secondarily, the C# style means you have to look both before and after th= e > property itself to know what its visibility rules are. That's increased > cognitive load. This way, all of the various "flags" on a property remai= n > in the same place, and presumably 99.999% of developers will put `public > private(set)` right next to each other like that. That makes the > visibility readable all from one spot, and if all you're using is that an= d > not accessors in the future, the impact on your existing reading skills i= s > minimized. This one is admittedly a bit more subjective, but readability > and cognitive load are certainly considerations to, er, consider. > Feedback: 1. The idea is cool 2. when I opened the RFC and looked at the syntax, I wasnt able to intuitively (self documenting code) figure out what and why was going on. 3. The syntax is heavily implicit as to what each keyword and syntax means, so the general PHP developer would struggle or mis understand what is going on. 4. MWOP's point of there being a lot of keywords and prefixes at class property declaration is not really cluttered (lots going on), is accurate. Perhaps splitting it into an explicit Attribute might yield a better DX? Ilina and Larry, all in all I know this is a WIP and you're looking for early feedback, so this is my feedback, to be considered. Looking forward to reviewing future revisions of this. Thanks for the effort and time you've put in so far <3 > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > --0000000000000af94705e583fa99--