Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110789
User-Agent: Cyrus-JMAP/3.3.0-dev0-576-gfe2cd66-fm-20200629.001-gfe2cd668
Mime-Version: 1.0
Message-ID: <24d956bc-c66a-4424-9bd9-bf975c6afa7a@www.fastmail.com>
In-Reply-To: 
 <CAEsg9X0QPFfZtOuDNX0m+iG033WU2OEDWj1-t6PLHiCfQWLThA@mail.gmail.com>
References: 
 <CAHRtwKbbsoh4kT5++43yJg9RH+aNnRCAiE+yLOO7tOfMjcjBGg@mail.gmail.com>
 <CAGgaK7LP5foae=zV7gKPhax4Sgp1D6BtQwPmwbe3CpPjpwqi+A@mail.gmail.com>
 <CAHRtwKbu0f6tN63RByFhWrgPKivihpdCW9maEW9QEDx1+j3n0A@mail.gmail.com>
 <5ef9f918.1c69fb81.58a86.e504SMTPIN_ADDED_MISSING@mx.google.com>
 <CADK1yXLFzqGcxHS4a0ow9Fwnb3MND1ujRG=R5-GDvt4KOOtVGg@mail.gmail.com>
 <CAEsg9X0QPFfZtOuDNX0m+iG033WU2OEDWj1-t6PLHiCfQWLThA@mail.gmail.com>
Date: Mon, 29 Jun 2020 16:15:06 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Property write visibility
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Jun 29, 2020, at 10:16 AM, David Rodrigues wrote:
> With all possibilities maybe we have:
>=20
> - public set:private unset:private isset:private get:private
>=20
> set:private could be readed like "set is private".
>=20
> Where:
>=20
> - public is "general visibility" for set, unset, isset and get;
> - set: affects write visibility;
> - unset: affects unset() visibility;
> - isset: affects isset() visibility;
> - get: affects read visibility;
>=20
> In this case, maybe we should think on possibility of usage like:
>=20
> class A {
>     get:public $x;
> }
>=20
> That determines that $x is private, except by get.
>=20
> In counterpart, I do not know if it makes sense for isset mode, becaus=
e if
> we have get:public, and $x is accessible, so it is isset by nature.
>=20
>=20
> Atenciosamente,
> David Rodrigues
>=20
>=20
> Em seg., 29 de jun. de 2020 =C3=A0s 12:03, Deleu <deleugyn@gmail.com> =
escreveu:
>=20
> > As a user, I would prefer the original proposed syntax `public:priva=
te` or
> > the Swift syntax `public private(set)` than the alternative syntax `=
public
> > int $x {protected set; protected unset;}`.
> >
> > On Mon, Jun 29, 2020 at 4:22 PM Mark Randall <marandall@php.net> wro=
te:
> >
> > > On 29/06/2020 15:13, Andr=C3=A9 R=C3=B8mcke wrote:
> > > > Would something closer to Swift be better? If so I expanded the =
RFC
> > with
> > > > that syntax option as well:
> > >
> > > Borrowing from the various accessors RFCs:
> > >
> > > public int $x {
> > >    protected set;
> > >    protected unset;
> > > }
> > >
> > > Then a future RFC can build upon it by adding the override functio=
ns
> > > while keeping the same base syntax.
> > >
> > > Mark Randall

Andre, thank you for this RFC.  I'm really glad to see asymmetric visibi=
lity getting more attention as I think it's a good example of a small ch=
ange with huge functionality potential.  This reply is me thinking aloud=
, so I apologize if it isn't quite linear.

For reference, I wrote about asymmetric visibility a few months back in =
my Object Ergonomics article:

https://peakd.com/php/@crell/improving-php-s-object-ergonomics

To recap what I said there:

* Yes please.  This change has a really good syntax-to-functionality rat=
io, and effectively solves the same problem as write-once or immutable p=
roperties in a much more flexible and PHP-ish way.
* Any syntax should absolutely be designed with future extension to prop=
erty accessors in mind.  Not because we are guaranteed to ever have them=
, but because they're hard enough as is to implement (which is why we do=
n't have them yet) so no sense adding more syntactic noise to make them =
even harder.

To that, I would also add:

* We should keep in mind that between constructor promotion and annotati=
ons, property syntax is starting to get potentially rather busy.
* Self-documenting syntax is good syntax.

Off the bat, therefore, I prefer get:public set:private.  It's nicely se=
lf-documenting, order doesn't matter, and we can ignore isset/unset for =
now but if we do find a need for them later the pattern is cleanly exten=
sible to that.

Which would lead to the following possible code in PHP 8:

class Point {
  public function __construct(
    @@Positive
    get:public set:private int $x,

    @@Positive
    get:public set:private int $y,

    @@Positive
    get:public set:private int $z,
  ) {}
}

Which is honestly pretty nice, especially compared to what it would be i=
n 7.4.

However, now expand that to include accessors in a hypothetical future (=
these are pointless accessor methods but just to keep the example consis=
tent):

class Point {
  public function __construct(
    @@Positive
    get:public {return $this->x; }=20
    set:private(int $x) { $this->x =3D $x; }
      int $x,

    @@Positive
    get:public {return $this->y; }=20
    set:private(int $y) { $this->y =3D $y; }
      int $y,

    @@Positive
    get:public {return $this->z; }=20
    set:private(int $x) { $this->z =3D $z; }
      int $z,
  ) {}
}

Now it's getting weird, primarily because the methods all come before th=
e variable declaration.  That may be comfortable for German speakers but=
 not for the rest of us. ;-)  It's also much worse if the accessor metho=
ds are multi-line.

That's why the previous accessor RFC settled on putting methods in a blo=
ck after the variable definition.

One possible solution to that is, were an accessor RFC to be introduced =
in the future, that it would repeat the get/set keyword only:

class Point {
  get:public set:private int $x {
    get { return $this->x; }
    set ($x) { $this->x =3D $x; }
  }

  get:public set:private int $y {
    get { return $this->y; }
    set ($y) { $this->y =3D $y; }
  }

  get:public set:private int $z {
    get { return $this->z; }
    set ($z) { $this->z =3D $z; }
  }

  public function construct(...) {}
}

That's a bit redundant, but... I think probably acceptable.

So, I think I'd favor get:X set:Y as modifiers, with the assumption that=


1) Should accessors ever happen they'd be expected to NOT duplicate the =
visibility, either with the option above or something similar.

2) isset and unset can be skipped for now but the RFC can explicitly sta=
te that should they ever be needed, they'd be added in the same way.

Here endeth my analysis.  Thanks again, Andre!

--Larry Garfield