Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118427
Message-ID: <200696F8-DDD6-4C15-8EA9-FEFC04B38688@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_751442BB-B431-4C55-B29F-3BB6DF336F8F"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Date: Fri, 12 Aug 2022 03:56:09 -0400
In-Reply-To: <6a52a2bc-a6ec-4d69-bc77-4c4b48f63a29@www.fastmail.com>
Cc: =?utf-8?Q?Bj=C3=B6rn_Larsson?= <internals@lists.php.net>,
 php internals <internals@lists.php.net>
To: Ollie Read <php@ollie.codes>
References: <ec4bc6e5-39ac-4a36-9d63-cca8dc6a29a6@www.fastmail.com>
 <6576371A-9C18-4BC4-ADA6-8F364208BF01@newclarity.net>
 <6a52a2bc-a6ec-4d69-bc77-4c4b48f63a29@www.fastmail.com>
Subject: Re: [PHP-DEV] [RFC] Asymmetric visibility
From: mike@newclarity.net (MKS Archive)

--Apple-Mail=_751442BB-B431-4C55-B29F-3BB6DF336F8F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Ollie,

> On Aug 8, 2022, at 6:12 AM, Ollie Read <php@ollie.codes> wrote:
>=20
> On Mon, Aug 8, 2022, at 3:54 AM, Mike Schinkel wrote:
>> 3.) I have concerns about the proposed methods isProtectedSet() and =
isPrivateSet(). =20
>>=20
>> These names feels like we are asking if some thing "Set" is =
"Protected" or "Private" where no such "thing" exists in this context. =20=

>>=20
>> 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.
>>=20
>> 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:
>>=20
>> isSetProtected()
>> isSetPrivate()
>> isGetProtected(), and
>> isGetPrivate()
>=20
> 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.=20

On my 3rd point that you quoted my primary concern was that I felt the =
RFC solution of "is<Visbility>Set()" was hard to reason about but my own =
suggestion almost incidental. I felt if I voiced my concerns then it =
would be incumbent upon me to at least suggest an alternative.

OTOH, I'm not sure I would embrace yet another reflection class. I think =
that would make an already (IMO) too-complex reflection class hierarchy =
even more complex.

Maybe a better solution could be to add an optional $flags parameter to =
the existing is<Visbility>() methods, something like?

isPublic(ReflectionProperty::GETTABLE)
isProtected(ReflectionProperty::GETTABLE)
isPrivate(ReflectionProperty::GETTABLE)

isPublic(ReflectionProperty::SETTABLE)
isProtected(ReflectionProperty::SETTABLE)
isPrivate(ReflectionProperty::SETTABLE)

isPublic(ReflectionProperty::GETTABLE & ReflectionProperty::SETTABLE)
isProtected(ReflectionProperty::GETTABLE & ReflectionProperty::SETTABLE)
isPrivate(ReflectionProperty::GETTABLE & ReflectionProperty::SETTABLE)

#fwiw

-Mike

> 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.
>=20
> 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.
>=20
> ---
> Best Regards,
> *Ollie Read*


--Apple-Mail=_751442BB-B431-4C55-B29F-3BB6DF336F8F--