Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109954
User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1
Mime-Version: 1.0
Message-ID: <6aa2bc2a-78c6-4eb5-a612-84978388633a@www.fastmail.com>
In-Reply-To: <647703CF-1015-4FBF-868F-8E3525706A43@benramsey.com>
References: 
 <CAPNm5sMWF=XOe-H_erfSm0jPerAxKGnXENetbbH+BUZDi+yiiw@mail.gmail.com>
 <647703CF-1015-4FBF-868F-8E3525706A43@benramsey.com>
Date: Fri, 01 May 2020 10:22:37 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Simplify classes syntax proposal
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, May 1, 2020, at 10:02 AM, Ben Ramsey wrote:
> > On May 1, 2020, at 09:44, Max D <max@bukrek.net> wrote:
> >=20
> > Greetings, Internals!
> >=20
> > This is my first try to input the proposal, please don't be strict )=

> >=20
> > All the years with PHP I hate writing classes. The need to prefix EV=
ERY
> > property and method use looks horrible and writes horrible. So, the
> > proposal:
> >=20
> > Lets introduce directive
> > declare(simple_classes=3D1);
> >=20
> > This directive will switch interpreter mode, where class declared
> > properties and methods are accessible as regular variables and funct=
ions at
> > class code.
> >=20
> > So, such a fragment
> >=20
> > public function __construct() {
> >   $this->get =3D $this->clean($_GET);
> >   $this->post =3D $this->clean($_POST);
> >   $this->request =3D $this->clean($_REQUEST);
> >   $this->cookie =3D $this->clean($_COOKIE);
> >   $this->files =3D $this->clean($_FILES);
> >   $this->server =3D $this->clean($_SERVER);
> > }
> >=20
> > will look so with the proposed directive:
> >=20
> > public function __construct() {
> >   $get =3D clean($_GET);
> >   $post =3D clean($_POST);
> >   $request =3D clean($_REQUEST);
> >   $cookie =3D clean($_COOKIE);
> >   $files =3D clean($_FILES);
> >   $server =3D clean($_SERVER);
> > }
> >=20
> > What do we lose with such an approach? The ability to use local vari=
ables
> > named as class properties and the ability to call regular functions,=
 called
> > as class methods. Both things are super-rarely used and programmers =
have
> > the ability to change naming to achieve them.
> >=20
> > For static properties/methods, dynamic ones will have an advantage i=
f
> > naming matches.
> > Of course, the ability to use usual prefixes will be preserved.
> >=20
> > I'm not going to implement this, hoping someone will volunteer if th=
e
> > reaction is positive.
> > Also I have some more proposals I will post if this one goes nice.
> >=20
> > With best regards,
> > MaxD
>=20
>=20
> Hi, MaxD!
>=20
> Is there a particular problem you=E2=80=99re trying to solve with this=
=20
> proposal? You say, =E2=80=9CAll the years with PHP I hate writing clas=
ses. The=20
> need to prefix EVERY property and method use looks horrible and writes=
=20
> horrible.=E2=80=9D
>=20
> I=E2=80=99m generally in favor of changes that make it easier for deve=
lopers to=20
> do their jobs well, but I don=E2=80=99t think writing `$this->` in fro=
nt of=20
> property and method names is a detriment to the development process. I=
n=20
> fact, I think it aids in writing safe code. Without `$this->`, it=E2=80=
=99s=20
> possible to unknowingly use or overwrite a class property, when that i=
s=20
> not the intent. I think this leads to a poor developer experience, so =
I=20
> would be against this change.
>=20
> Cheers,
> Ben


I don't think it's even possible as long as PHP allows variables to defi=
ned on first use..

class Foo {
  public function bar() {
    $beep =3D '5';
  }
}

Is $beep a local variable or an object property?  You could say "well of=
 course it's a local variable" and that would be my guess as well, but i=
t's entirely valid to think of it the other way around since object prop=
erties can also be created on-the-fly currently.  (Many people have argu=
ed they shouldn't be, but that's the status quo.)  Or if you later add a=
 $beep object property, then as Ben notes you've just changed the $beep =
in bar() to mean the object property, which can cause all sorts of weird=
 bugs.

Remember, many classes are way longer than this example and may have man=
y properties, so it's easier to accidentally reuse a property name as a =
variable than you think, and the compiler will be completely unable to c=
atch it for you.  That's in contrast to languages like Java where explic=
it variable declaration means that the compiler can definitively tell wh=
ich you mean at compile time and tell you if it's confused.

Of note, Go, Rust, and Swift all require you to specify some prefix to i=
ndicate the scope of the variable you mean.  If anything, requiring the =
prefix seems to be more common with newer languages.  It's apparently no=
t enough of an ergonomics issue that greenfield languages are avoiding i=
t.  They're actually using it in droves.

--Larry Garfield