Simplify classes syntax proposal View as Markdown

Greetings, Internals!

This is my first try to input the proposal, please don't be strict )

All the years with PHP I hate writing classes. The need to prefix EVERY
property and method use looks horrible and writes horrible. So, the
proposal:

Lets introduce directive
declare(simple_classes=1);

This directive will switch interpreter mode, where class declared
properties and methods are accessible as regular variables and functions at
class code.

So, such a fragment

public function __construct() {
$this->get = $this->clean($_GET);
$this->post = $this->clean($_POST);
$this->request = $this->clean($_REQUEST);
$this->cookie = $this->clean($_COOKIE);
$this->files = $this->clean($_FILES);
$this->server = $this->clean($_SERVER);
}

will look so with the proposed directive:

public function __construct() {
$get = clean($_GET);
$post = clean($_POST);
$request = clean($_REQUEST);
$cookie = clean($_COOKIE);
$files = clean($_FILES);
$server = clean($_SERVER);
}

What do we lose with such an approach? The ability to use local variables
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.

For static properties/methods, dynamic ones will have an advantage if
naming matches.
Of course, the ability to use usual prefixes will be preserved.

I'm not going to implement this, hoping someone will volunteer if the
reaction is positive.
Also I have some more proposals I will post if this one goes nice.

With best regards,
MaxD

Hi, MaxD!

Is there a particular problem you’re trying to solve with this
proposal? You say, “All the years with PHP I hate writing classes. The
need to prefix EVERY property and method use looks horrible and writes
horrible.”

I’m generally in favor of changes that make it easier for developers to
do their jobs well, but I don’t think writing $this-> in front of
property and method names is a detriment to the development process. In
fact, I think it aids in writing safe code. Without $this->, it’s
possible to unknowingly use or overwrite a class property, when that is
not the intent. I think this leads to a poor developer experience, so I
would be against this change.

Cheers,
Ben

I don't think it's even possible as long as PHP allows variables to defined on first use..

class Foo {
public function bar() {
$beep = '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 it's entirely valid to think of it the other way around since object properties can also be created on-the-fly currently. (Many people have argued 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 many 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 catch it for you. That's in contrast to languages like Java where explicit variable declaration means that the compiler can definitively tell which 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 indicate the scope of the variable you mean. If anything, requiring the prefix seems to be more common with newer languages. It's apparently not enough of an ergonomics issue that greenfield languages are avoiding it. They're actually using it in droves.

--Larry Garfield

Thank you for the replies!

Take note, that this directive is optional, so it will be used by
programmers that would like this coding style.
Of course, it will make code reading more challenging. But, from the other
side, code will look more clean and human like, making understanding the
logic easier.
Now it looks like some core dumps, especially with self:: prefixes.
Without syntax highlighting it's barely readable.

Just to mention, C++ and Pascal have such simple referring scheme without
alternatives.
Millions of programmers write and read such code from the beginning of
classes up to now.

With best regards,
MaxD

пт, 1 трав. 2020 о 18:02 Ben Ramsey ben@benramsey.com пише:

Greetings, Internals!

This is my first try to input the proposal, please don't be strict )

All the years with PHP I hate writing classes. The need to prefix EVERY
property and method use looks horrible and writes horrible. So, the
proposal:

Lets introduce directive
declare(simple_classes=1);

This directive will switch interpreter mode, where class declared
properties and methods are accessible as regular variables and functions
at
class code.

So, such a fragment

public function __construct() {
$this->get = $this->clean($_GET);
$this->post = $this->clean($_POST);
$this->request = $this->clean($_REQUEST);
$this->cookie = $this->clean($_COOKIE);
$this->files = $this->clean($_FILES);
$this->server = $this->clean($_SERVER);
}

will look so with the proposed directive:

public function __construct() {
$get = clean($_GET);
$post = clean($_POST);
$request = clean($_REQUEST);
$cookie = clean($_COOKIE);
$files = clean($_FILES);
$server = clean($_SERVER);
}

What do we lose with such an approach? The ability to use local variables
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.

For static properties/methods, dynamic ones will have an advantage if
naming matches.
Of course, the ability to use usual prefixes will be preserved.

I'm not going to implement this, hoping someone will volunteer if the
reaction is positive.
Also I have some more proposals I will post if this one goes nice.

With best regards,
MaxD

Hi, MaxD!

Is there a particular problem you’re trying to solve with this proposal?
You say, “All the years with PHP I hate writing classes. The need to prefix
EVERY property and method use looks horrible and writes horrible.”

I’m generally in favor of changes that make it easier for developers to do
their jobs well, but I don’t think writing $this-> in front of property
and method names is a detriment to the development process. In fact, I
think it aids in writing safe code. Without $this->, it’s possible to
unknowingly use or overwrite a class property, when that is not the intent.
I think this leads to a poor developer experience, so I would be against
this change.

Cheers,
Ben

Forgot to add.

As for me, poor developers experience is that I am forced to write the same
6-symbols prefix with 1 or 2 Shift-keystrokes 20-30 times per one code page

• without alternatives.

With best regards,
MaxD

пт, 1 трав. 2020 о 18:02 Ben Ramsey ben@benramsey.com пише:

Greetings, Internals!

This is my first try to input the proposal, please don't be strict )

All the years with PHP I hate writing classes. The need to prefix EVERY
property and method use looks horrible and writes horrible. So, the
proposal:

Lets introduce directive
declare(simple_classes=1);

This directive will switch interpreter mode, where class declared
properties and methods are accessible as regular variables and functions
at
class code.

So, such a fragment

public function __construct() {
$this->get = $this->clean($_GET);
$this->post = $this->clean($_POST);
$this->request = $this->clean($_REQUEST);
$this->cookie = $this->clean($_COOKIE);
$this->files = $this->clean($_FILES);
$this->server = $this->clean($_SERVER);
}

will look so with the proposed directive:

public function __construct() {
$get = clean($_GET);
$post = clean($_POST);
$request = clean($_REQUEST);
$cookie = clean($_COOKIE);
$files = clean($_FILES);
$server = clean($_SERVER);
}

What do we lose with such an approach? The ability to use local variables
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.

For static properties/methods, dynamic ones will have an advantage if
naming matches.
Of course, the ability to use usual prefixes will be preserved.

I'm not going to implement this, hoping someone will volunteer if the
reaction is positive.
Also I have some more proposals I will post if this one goes nice.

With best regards,
MaxD

Hi, MaxD!

Is there a particular problem you’re trying to solve with this proposal?
You say, “All the years with PHP I hate writing classes. The need to prefix
EVERY property and method use looks horrible and writes horrible.”

I’m generally in favor of changes that make it easier for developers to do
their jobs well, but I don’t think writing $this-> in front of property
and method names is a detriment to the development process. In fact, I
think it aids in writing safe code. Without $this->, it’s possible to
unknowingly use or overwrite a class property, when that is not the intent.
I think this leads to a poor developer experience, so I would be against
this change.

Cheers,
Ben

Thank you guys for all your feedback!

It's a big surprise for me that so many people love PHP for this style of
referring.
Sure, I am out of the pack. I am stuck to PHP due to my activity type and
mostly write a lot of code no one reads except me.

I have found my own way to deal with it. Mostly PHP classes are used once
per session, so I mimic the desired approach by using regular procedures +
global variables.
Sure, that is not good style, but that's the only choice I have.

Anyway, long live PHP ;-)

With best regards,
MaxD

пт, 1 трав. 2020 о 20:11 Arvids Godjuks arvids.godjuks@gmail.com пише:

Greetings, Internals!

This is my first try to input the proposal, please don't be strict )

All the years with PHP I hate writing classes. The need to prefix EVERY
property and method use looks horrible and writes horrible. So, the
proposal:

Lets introduce directive
declare(simple_classes=1);

This directive will switch interpreter mode, where class declared
properties and methods are accessible as regular variables and functions
at
class code.

So, such a fragment

public function __construct() {
$this->get = $this->clean($_GET);
$this->post = $this->clean($_POST);
$this->request = $this->clean($_REQUEST);
$this->cookie = $this->clean($_COOKIE);
$this->files = $this->clean($_FILES);
$this->server = $this->clean($_SERVER);
}

will look so with the proposed directive:

public function __construct() {
$get = clean($_GET);
$post = clean($_POST);
$request = clean($_REQUEST);
$cookie = clean($_COOKIE);
$files = clean($_FILES);
$server = clean($_SERVER);
}

What do we lose with such an approach? The ability to use local variables
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.

For static properties/methods, dynamic ones will have an advantage if
naming matches.
Of course, the ability to use usual prefixes will be preserved.

I'm not going to implement this, hoping someone will volunteer if the
reaction is positive.
Also I have some more proposals I will post if this one goes nice.

With best regards,
MaxD

This clashes with local scope variable definition, that's one and as
others mentioned - it plain simple probably is not possible to implement
unless you make a special exclusion for __construct and that's a horrible
horrible idea (just look at the history of PHP how making special handling
of things turned out).

Second - code readability. You write code once, you may modify it once in
a blue moon (it being a constructor makes it far less touched). But you and
your colleagues, including future developers, read that code constantly and
it will be just plain confusing to read that code. $this-> makes it
explicit you work with the class properties and it's a good thing.

Third - these days, if people are bothered with writing repeating code,
there are a lot of tooling that makes it super easy - from code generation
to code completion in various editors and IDE's (PhpStorm being my personal
preference - all I need to do is write constructor arguments - IDE will
generate class properties and assign them in the constructor in 2
keystrokes). Refusing to use the tools is a personal preference of each
individual, but that also means those individuals can't start to request
all the syntax sugar they can just to make their life easier a little bit
at the expense of things like code readability or other people having to
learn a crapload of syntax sugar and deal with it.

On a personal note: If you want a lot of syntax sugar and fancy stuff -
there is Ruby and Python and other languages for that, that are doing it
better and are designed with all that in mind. PHP is a different type of
language, it's expressive and for the most part a straight forward one and
that makes development in it somewhat easy even with the bigger stuff. It
also makes junior devs pick it up easily and not make as many mistakes
because it is explicit and there is not much magic behind (well, unless you
use magic methods, but at least in my development environment we completely
don't use them at all - everything is explicitly defined).
There is a line where you have to think about the fact that maybe it's
time to switch languages because you want different things and the language
you are using is not suited for that any more. The right tool for the job
principle. For example, I tried myself some Ruby and I don't like it as a
language and I'm sticking to PHP for web development as my tool exactly
because of syntax it has, limited amounts of magic and with 7 series it
having tons of improvements on the error and variable handling that allow
me to write stricter code + all the tooling in the ecosystem.

Some improvements to the language are nice, there for sure have been some
good once. But it needs to fit the PHP and this proposal is pure and simple
"out there" and, clearly, has not even been considered if it's technically
feasible, and as far as I know, the PHP AST parser just can't handle this
ambiguous case (and it will be a bad special case).

--
Arvīds Godjuks

+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius