Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112129
User-Agent: Cyrus-JMAP/3.3.0-529-g69105b1-fm-20201021.003-g69105b13
Mime-Version: 1.0
Message-ID: <3af046e2-2647-4b9a-907e-47c2043ad60f@www.fastmail.com>
In-Reply-To: <FF0F9F19-F9AE-4DEA-BE3B-D9DA85FAB0A6@newclarity.net>
References: <eb143f8b-b242-47bb-9858-e6150dd7aea4@www.fastmail.com>
 <CABdc3WomkCRkUL0yrMA=y=Nt+QUVH1W9mAz-wm_tB3mkg_woOw@mail.gmail.com>
 <FF0F9F19-F9AE-4DEA-BE3B-D9DA85FAB0A6@newclarity.net>
Date: Tue, 27 Oct 2020 11:31:55 -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] Short-function syntax
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Oct 27, 2020, at 1:35 AM, Mike Schinkel wrote:
>=20
>=20
> > On Oct 26, 2020, at 10:23 AM, Micha=C5=82 Marcin Brzuchalski <michal=
.brzuchalski@gmail.com> wrote:
> >=20
> > Hi Larry,
> >=20
> > I'm wondering why we hadn't thought yet about reducing the need for =
$this
> > in this syntax.
> > Since arrow functions have an ability to capture variables defined i=
n
> > parent scope why not
> > think of the same for class properties which will automatically redu=
ce
> > short methods verbosity.
> >=20
> > class X {
> >    public function __construct(private int $foo, private int $bar) {=
}
> >    public function getFoo(): int =3D> $foo;
> >    public function getBar(): int =3D> $bar;
> > }
> >=20
> > And then going further why not removing =3D from arrow which indicat=
ed that
> > there is no return value for void functions:
> >=20
> > class X {
> >    public function __construct(private int $foo, private int $bar) {=
}
> >    public function getFoo(): int =3D> $foo;
> >    public function setFoo(int $value): void > $foo =3D $value;
> >    public function getBar(): int =3D> $bar;
> >    public function setBar(int $value): void > $bar =3D $value;
> > }
> >=20
> > The use of > instead of =3D> could if possible indicate the method b=
eing void
> > and reduce even more:
> >=20
> > class X {
> >    public function __construct(private int $foo, private int $bar) {=
}
> >    public function getFoo(): int =3D> $foo;
> >    public function setFoo(int $value) > $foo =3D $value;
> >    public function getBar(): int =3D> $bar;
> >    public function setBar(int $value) > $bar =3D $value;
> > }
> >=20
> > Would it be possible?
> >=20
> > If not I think we should reanimate property accessors.
>=20
> Which brings us back to https://externals.io/message/64469=20
> <https://externals.io/message/64469> from 7 years ago.  And there is=20=

> this:=20
> https://www.reddit.com/r/PHP/comments/budr7q/php_74_setters_and_getter=
s_have_died/ <https://www.reddit.com/r/PHP/comments/budr7q/php_74_setter=
s_and_getters_have_died/>
>=20
> With getters/setters, it would seem Larry's proposal might allow for=20=

> more conciseness than it can with all other current syntax being the=20=

> same as PHP 8.0 per Nikita.=20
>=20
> Consider this, as one straw man type of new syntax:
>=20
> class TimePeriod {
> 	private int $Seconds =3D 3600;
> 	public float $Hours {
> 		get():float =3D> $this->Seconds / 3600;
> 		set(int $v) =3D> $this->Seconds =3D intval($v*3600);
> 	}
> }
>=20
> Or for a different use-case with different straw man syntax that could=
=20
> possibly work in addition to above syntax, where externally $Balance i=
s=20
> readonly whereas internally Balance is treated like it is private so i=
t=20
> can be set (I also used Michal's ">" to indicate void, although I am=20=

> not sure that using a greater-than in a different context is a good=20=

> idea):
>=20
> class Account {
> 	public get int $Balance;
> 	public function Deposit(int $amount) > $this->Balance +=3D $amount;
> 	public function Withdraw(int $amount) > $this->Balance -=3D $amount;
> }

Responding to several things at once here:

Honestly, getters is not my primary target with this RFC.  They're more =
a nice side effect, given how common they are.  I am more interested in =
"expression functions": functions that are just a pure input->output map=
.  Sometimes those are methods, but frequently they're just functions.

A shortened setter is not really what I'm after, therefore.  If anything=
, I'd prefer to make an expression that returns a new object with one ch=
ange that can then be returned by this syntax, making with-er methods ea=
sier.  That would fit better with value objects. =20

And, in fact, named parameters already gives us something very very clos=
e in 8.0:

class Point {
    public function __construct(private int $x, private int $y) {}

    protected function modClone(...$args): static {
        $new =3D clone($this);
        foreach ($args as $k =3D> $v) {
            $new->$k =3D $v;
        }
        return $new;
    }
   =20
    public function moveUp(int $amt) {=20
        return $this->modClone(y: $this->y + $amt);
    }=20
}

$p1 =3D new Point(3, 5);

$p2 =3D $p1->moveUp(4);

https://3v4l.org/lg4Ac

That allows for a single-expression with-er method with no additional sy=
ntax, just one simple utility method.  Which, with this RFC, could be sh=
ortened to:

class Point {
    public function __construct(private int $x, private int $y) {}

    protected function modClone(...$args): static {
        $new =3D clone($this);
        foreach ($args as $k =3D> $v) {
            $new->$k =3D $v;
        }
        return $new;
    }
   =20
    public function x(): =3D> $this->x;
    public function y(): =3D> $this->y;

    public function distFromOrigin() =3D> sqrt($this->x ** 2 + $this->y =
** 2);

    public function moveUp(int $amt): static =3D> $this->modClone(y: $th=
is->y + $amt);
}

Which... I actually really like, now that I look at it.  I'd rather look=
 at how to make modClone() more trivial or even included natively than a=
 dedicated setter syntax.  But that's for another RFC.

That's also why I don't really want to consider auto-scoping to $this.  =
That's unnecessary magic that would, if anything, make converting betwee=
n a short and long function harder.  At this point I can type $this-> fr=
om pure muscle memory in a fraction of a second so I'm not too bothered =
by it. :-)

To Nikita's point about visual confusion in a class, that's fair.  Howev=
er, as noted I think it's more useful for functions anyway.  Also, the p=
roblem goes away if you cluster your code effectively, which is already =
a good (albeit not universal) practice, and if you can use a with-er sty=
le method as above.

viz:

class User {
  public function __construct(
    private int $id,=20
    private string $username,=20
    private string $role,=20
    private string $firstName,=20
    private string $lastName,
  ) {}

  public function getId(): int =3D> $this->id;
  public function getUserName(): string =3D> $this->username;
  public function getRole(): string =3D> $this->role;
  public function getFullName(): string =3D> sprintf(%s %s', $this->firs=
tName, $this->lastName);

  public function setUserName(string $name): static =3D> $this->modClone=
(username: $name);
  public function setRole(string $role): static =3D> $this->modClone(rol=
e: $role);

  public function rehashPassword(): void {
    // ... Stuff here.
  }
}

That looks quite readable to me, and even encourages putting all the sim=
ple getters together, both those that are raw getters and the "pseudo-pr=
operty" ones like getFullName().  Looking at it, I quite like it both vi=
sually and for what it encourages.

--Larry Garfield