Re: [RFC] Asymmetric visibility

> On Aug 5, 2022, at 1:08 PM, Larry Garfield <larry@garfieldtech.com> wrote: > > 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 Conceptually, I believe this would add useful capabilities to PHP that are impossible to implement without: a.) Likely-sizable performance penalties, and b.) Unfortunate edge-cases; e.g. property_exists(), get_object_vars(), etc. Still, here are my concerns with the RFC as it currently exists: 1.) The syntax of "<keyword>(<keyword>)" feels inconsistent with the rest of the language. PHP has function(args...) and (<type>), both of which can be viewed as "a function of 'args'." However, "private(set)" is basically a constraint, not a "function of 'set'." PHP also has function(args...):<type> which is a constraint so I propose we consider the following syntax instead: <visibility>:<operation> Thus all of these: public:get public:set private:get private:set protected:get protected:set 2.)The idiom "public private:set" is hard to reason about when reading, at least for me. It also feels inconsistent in that it requires one type of visibility to be constrained, but not the other. Speaking of "explicit" from one of Larry's latest replies, I propose we consider requiring asymmetric visibility *explicitly* declared, in all cases. Requiring explicit declaration would: a.) Make asymmetric visibility easier to reason about, and b.) Ensure consistency when asymmetric visibility is used. Specifically I would propose we make these INVALID: public protected:set <type> $<var>; public private:set <type> $<var>; protected private:set <type> $<var>; But all of these following VALID: These as-is for backward compatibility and an obvious default behavior: public [<type>] $<var>; protected [<type>] $<var>; private [<type>] $<var>; And these where behavior is explicit: public:get protected:set <type> $<var>; public:get private:set <type> $<var>; protected:get private:set <type> $<var>; As well as these: public:set protected:get <type> $<var>; public:set private:get <type> $<var>; protected:set private:get <type> $<var>; And of course these: public:get public:set <type> $<var>; private:get private:set <type> $<var>; protected:get protected:set <type> $<var>; 3.) I have concerns about the proposed methods isProtectedSet() and isPrivateSet(). These names feels like we are asking if some thing "Set" is "Protected" or "Private" where no such "thing" exists in this context. In other words it reads as if you are asking "Is it a *protected* Set?" or "Is it a *private* Set?" Such naming also does not relate to the Property itself which is what the prefix verb "is" is acting on. I would propose instead we consider the following are these instead would be asking the *ability* to "Set" the Property is "Protected" or "Private" where The Property is again what the prefix verb "is" is acting on: isSetProtected() isSetPrivate() isGetProtected(), and isGetPrivate() #jmtcw -Mike