Re: [RFC] Asymmetric visibility

On Mon, Aug 8, 2022, at 3:54 AM, Mike Schinkel wrote: > 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() I feel almost as if we shouldn't pollute ReflectionProperty with these additional methods but should instead have something like ReflectionAsymmetricProperty, which would in turn extend ReflectionProperty. I guess it depends on how it's handled. If all property handling is updated so that "public int $number" is identical to "public:get public:set int $number", there's no issue, but if we treat those with separate visibilities to be additional, it probably makes sense to be somewhat separate. While isGetProtected() is technically false for "public int $number", if it's not inferred, it's semantically incorrect. A good example of this is ReflectionMethod::getPrototype, which throws an exception if there's no prototype. Although this is somewhat bizarre, it is at least a thing we do. --- Best Regards, *Ollie Read*