PHP RFC: Instance Reference Sugar 0.2

instance-reference-sugar-rfc-0.2.php

====== PHP RFC: Instance Reference Sugar ======
  * Version: 0.2
  * Date: 2015-03-09
  * Author: Shawn McCool, shawn@heybigname.com
  * Status: In Discussion

===== Summary =====

In order to access instance variables and methods, one must use the `$this->` prefix.

The problem with this is that it reduces expressiveness in the language and increases the amount of unnecessary decoration, reducing readability.

This RFC proposes a single character syntax sugar form of `$this->`. Instead, an `@` can be used to reference instance variables and methods.

The @ replaces the normal $ variable prefix.

===== Example =====

<file php Addition.php>
<?php
class Addition {
  private $number

  public function __construct($number) {
    @number = $number;
  }

  public function original() {
    return @number;
  }

  public function addTo($amount) {
    return @add(@number, $amount);
  }

  private function add($one, $two) {
    return $one + $two;
  }
}
</file>

===== Implementation =====

@ is basically a macro that expands to `$this->`

===== Backwards Compatibility =====

Leave `$this->` available.

@ is currently used for error suppression. This error suppression format should be removed in favor of error exceptions.

===== Proposed PHP Version(s) =====

This is proposed for the next PHP x, currently PHP 7.

OK, let's go through this part by part

Syntax

Re-using the @ error suppression operator is a really bad idea. For one, return @number is ambiguous between your functionality and an error-suppressed constant lookup.

Removing (deprecating) the @ operator for error suppression is a bad idea. This is due to operations like mkdir() and fopen() being literally impossible to code in a way that can never throw an error. It is also due to the fact that it's a massive BC break.

So @ is off the table.

But there's another syntax choice we could re-use. ->. Which would turn your example into:

class Addition {
    private $number

    public function __construct($number) {
        ->number = $number;
    }

    public function original() {
        return ->number;
    }

    public function addTo($amount) {
        return ->add(->number, $amount);
    }

    private function add($one, $two) {
        return $one + $two;
    }
}

This has the added benefit that it's already used for this type of access. And since it already requires an expression before it in the parser, it shouldn't create any ambiguity.

Concept

You make the following claim about $this->:

The problem with this is that it reduces expressiveness in the language and increases the amount of unnecessary decoration, reducing readability.

I disagree. I think it increases expressiveness and increases readability. Compare it to Java which doesn't "decorate" method calls on this. Instead, you need coding conventions like _ prefix notation to determine where a variable is declared (to distinguish member variables from local ones).

In fact, if we look at languages that are design explicitly for "expressiveness" like CoffeeScript, we notice that they still use an explicit this prefix for self-access.

In fact, the only really major language that I could find (please correct me if I'm wrong here) that gives special syntax to this is Ruby.

Why does Ruby do this? Is it because it's more expressive?

In Ruby, you don't need () for method calls. Which means that it's impossible to tell the difference between self.a meaning a method call and meaning a property access. So it's always a method call.

So what choices are left? The direction they chose was to make as much as possible into a method call. In fact, it has a macro (basically) attr_reader to expand a list of names into accessor methods.

Meaning that no class outside the current instance needs to access properties. Well, normally. If you do, you can use obj.instance_variable_get(:@varname). However, that's horrible syntax, so nobody does that (instead they "encapsulate" and provide getters/setters).

However, there would be another alternative. You could have used special syntax to distinguish method calls from property accesses. Most other programming languages do this by using () syntax to distinguish them (so ->foo is a property, and ->foo() is a method). What if we were to do something like that in Ruby? You could do obj@property or obj->property instead of using .. That would eliminate the ambiguity and provide the ability to easily access properties from outside the object.

But they chose not to. They instead chose to make methods the convention (which is fine). So therefore there's no need to access properties outside the instance, therefore there's no need for that syntax. Therefore there's no gain in requiring this in any form other than duplication (since there's no way to access the property on other objects). Therefore, @property is all they need.

When we look at method calls, languages like Ruby and Java get away without needing this prefixes because they don't have first-class named functions. So there's no need to distinguish between foo() being a method call or a function call, because there are no such things as functions.

In PHP, none of these limitations apply. We have functions, and we can access properties across instances. Therefore, dropping all syntax isn't possible.

That raises the question: is it worth saving the 5 characters to type $this. Does that reduce expressiveness or increase readability?

I would argue no: it doesn't reduce expressiveness at all, and it doesn't decrease readability to have $this before method calls/property accesses. It may be slightly faster to type without having to do $this, but is that a big gain?

Considering that most major languages other than Java and Ruby use this everywhere, and considering that Java and Ruby are able to do that because of other design tradeoffs that let them drop it (which PHP doesn't make), I'm not sure I can see the gain.

What I definitely don't expect from PHP.

Of course I agree with '@' not being an option. I actually laughed for like 20 seconds straight when I added the line to backwards compatibility about removing error suppression.

I agree that this reference is important. But, I disagree that such a change as this wouldn't increase readability.

I'm not particularly interested in Ruby. However, the nice thing about Ruby (relevant to this conversation) is that it conforms to the uniform access principle. I agree that this probably isn't the right choice for PHP.

What I'm looking for.

Ideally, I'd like to see PHP scoping modified to support direct field access from methods.

class MyClass {
    private $var;
    public function getVar() {
        return $var;
    }
}

This requires $this-> for referencing fields when names exist in the function.

I realize that I'm just not going to get that. I figured I might throw a proposal for a macro on the table.

I always enjoy using languages that allow access to fields in this way. There's really NOT a need for _ prefix because you do have the ability to reference this.

So, constructors can still be crazy as normal:

$this->whatever = $whatever;
$this->meow = $meow;

But, actual methods that have the behavior can be cleaner and more concise. One thing that I find sub-optimal in PHP is the heavy amount of decoration used.

I do know that we won't agree on what makes nicer to use / read syntax. But, I very much appreciate you spending your time talking to me about this.

Thanks, Anthony.

I'm not arguing in general about the heavy amount of decoration used in PHP. I just don't consider $this-> to be decoration or heavy. Other areas: function () use ($bar) {}, sure. Or even protected static function blah()... I just don't consider this one to be a) bad or b) heavy.

As far as direct field access:

class MyClass {
    private $var;
    public function getVar() {
        return $var;
    }
}

I really don't like that syntax. In trivial examples, it's great. In complex examples (more than 100 loc) it can become really hard to track down. It requires you to either use an IDE or read through hundreds of lines of code to figure out (since you need to read the entire method body, as well as class definitions of the current class as well as any parent). That's why Java uses the _ prefix convention for member variables. So that it's easier to at a glance tell

And I'm strongly opposed to any feature that requires the use of an IDE to reasonably use.

But thanks for sharing the idea :-)

Is there any news on this? ;)
Would really like to see this implemented at some point.
Not sure I have any preference on the character used, just something shorter than $this-> xD