PHP RFC: Lexical Scope Support for Anonymous Classes

• Version: 0.2
• Date: 2016-04-19
• Author: krakjoe
• Status: Under Discussion
• First Published at: http://wiki.php.net/rfc/lexical-anon

Anonymous classes are cumbersome to use because they lack support for lexical scope [use()].

If the anonymous class has dependencies, they must be injected via the constructor, which is verbose, repetitive, and widens the margin for error considerably.

We allow anonymous classes to import variables into their property table using the familiar syntax.

The following syntax is used:

new class [extends Parent] [implements Interface] [use(...)] {}

Where use is one or more variables, property references, or a references to either.

The following code:

$glow = 5;
$foo = new class use($glow) {
 
};

Is functionally equivalent to:

$glow = 5;
$foo = new class($glow) {
    public function __construct($glow) {
        $this->glow = $glow;
    }
    private $glow;
};

By default, imported variables shall be declared private members of the anonymous class unless the class declaration overrides this behaviour, as the following example shows:

$glow = 5;
$foo = new class() use($glow) {
    public $glow;
};

References are also accepted, so that the following code:

$glow = 5;
$foo = new class() use(&$glow) {
 
};

Is functionally equivalent to:

$glow = 5;
$foo = new class($glow) {
    public function __construct(&$glow) {
       $this->glow =& $glow;
    }
    private $glow;
}; 

Placing the [use(...)] anywhere else in the class declaration seems to be confusing, the current position seems the obvious choice.

It has been suggested that it would be better to have [use(...)] on each function declaration. This would lead to a lot of repetition, and fragmented code that is more difficult to reason about.

Another suggestion made is to allow symbols inline, so that the following code is legal:

class {
    public $prop = $var;
}

This has some appealing advantages, such as using expression to initialize properties. But it also raises huge inconsistencies, why should this:

class {
    public $prop = new Foo();
}

Be allowed, while not allowing the same thing in normal classes.

Additionally, the following code would also have to be legal:

class {
    public $prop = &$this->prop;
}

This is almost literally backwards.

If we are going to allow expressions for anonymous classes that we do not allow for normal classes, then it is better to leave that for another RFC.

What we are doing is only importing symbols, we don't need to invent a new way to initialize them.

The cognitive overhead of “anything use'd by the declaration is a member property” is almost nil.

The same restrictions that apply to use() on function declarations apply:

• Must not be superglobal name
• Must not be $this

The property reference must be well formed, and accessible in the lexical scope:

$object->property

A property name cannot be used twice:

use($prop, $prop)

and

use($prop, $this->prop)

Will both raise compile time errors:

Fatal error: Cannot use property name glow twice in /in/file on line 6

What breaks, and what is the justification for it?

7.1

Trivial changes for new opcodes and new sequences.

Will need adjustment, rather trivial (if you are Dmitry)

Make sure there are no open issues when the vote starts!

2/3 majority required, simple yes/no vote.

https://github.com/php/php-src/pull/1874

After the project is implemented, this section should contain

1. the version(s) it was merged to
2. a link to the git commit(s)
3. a link to the PHP manual entry for the feature

Links to external references, discussions or RFCs

Keep this updated with features that were discussed on the mail lists.