On Fri, May 1, 2020, at 10:02 AM, Ben Ramsey wrote:
> > On May 1, 2020, at 09:44, Max D <m...@bukrek.net> wrote:
> > 
> > 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to