Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118377
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
In-Reply-To: <ec4bc6e5-39ac-4a36-9d63-cca8dc6a29a6@www.fastmail.com>
Date: Sun, 7 Aug 2022 22:54:02 -0400
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <6576371A-9C18-4BC4-ADA6-8F364208BF01@newclarity.net>
References: <ec4bc6e5-39ac-4a36-9d63-cca8dc6a29a6@www.fastmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Subject: Re: [PHP-DEV] [RFC] Asymmetric visibility
From: mike@newclarity.net (Mike Schinkel)

> On Aug 5, 2022, at 1:08 PM, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3: =
Asymmetric Visibility.
>=20
> 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=20
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.=20

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.=20

It also feels inconsistent in that it requires one type of visibility to =
be constrained, but not the other.=20

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:=20

a.) Make asymmetric visibility easier to reason about, and=20
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(). =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

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