PHP RFC: Compact Object Property Assignment

• Version: 0.9
• Date: 2020-03-10
• Author: Jakob Givoni jakob@givoni.dk
• Status: Draft

A pragmatic approach to mimicking object literals.

This RFC proposes a new, compact syntax to assign values to multiple properties on an object in a single expression.

$myObj->prop_a = 1;
$myObj->prop_b = 2;
$myObj->prop_c = 3;

$myObj->[
    prop_a = 1,
    prop_b = 2,
    prop_c = 3,
];

The purpose of this feature is to lighten the effort of populating data structures, especially medium to large ones.

Ideally the solution should meets the following criteria:

• Brief - only mention the object once (less repetition)
• Inline - object can be created and populated in a single expression (pseudo object literals, nested objects)
• Typo-proof - property names can be autocompleted easily by IDE (faster typing, fewer errors)
• Type-checking - IDE can verify correct type for typed properties and annotated virtual properties
• Order-agnostic - properties can be specified in any order (this doesn't mean that the result is necessarily the same for any ordering, as that will depend on the object implementation)
• Sparcity - there's no obligation to specify any particular property (non-specified properties may be given a default value)
• Simple - does what you would expect without introducing any new concepts into the language

The proposed syntax following an object expression $myObj | (new MyClass()) is the object arrow operator -> followed by a set of square brackets […] containing a comma-separated list of property name equals = expression. A trailing comma is permitted for the same reasons it's permitted in array literals and function calls (as of PHP 7.3). The whole block is considered an expression that returns the object we started with.

Each comma-separated assignment inside the brackets is executed as an assignment of the named property on the object preceding the block. If the property is defined and publicly accessible, it will simply be set, or possible throw a TypeError. If there's no property with that name, or if it's protected or private, the magic method __set will be called just like you would expect. When used in an expression, COPA simply returns the object itself.

Typical features of DTOs:

• many properties
• properties may be optional, with default values
• public visibility on properties, no need for boilerplate code to create setters and getters for each one

class Dto {
    public string $foo;
    public int $bar = 1; // Optional, with default
    public string $baz;
}
 
$myDto = new Dto(); // Instantiating the object first
$myDto->foo = 'get'; // Setting the properties
$myDto->baz = 'life';
 
myFunc($myDto); // Passing to a function

myFync((new Dto())->[ // Constructing and populating inline
    foo = 'get',
    baz = 'life',
]);

Argument bags are typically used when:

• many arguments needs to be passed to a function
• some arguments are optional
• order of arguments is not important

With the proposed COPA syntax we can avoid using simple arrays and instead get autocomplete and type-checking in the IDE with a syntax that smells of named parameters:

class Foo {
    protected string $foo;
    protected int $bar;
    protected string $baz;
 
    public function __construct(array $options) {
        $this->foo = $options['foo'];
        $this->bar = $options['bar'] ?? 1;
        $this->baz = $options['baz'];
    }
}
 
$myFoo = new Foo([
    'foo' => 'get', // Array syntax argument bag doesn't provide any help on parameter names 
    'baz' => 'life', // or types
]);

class Foo {
    protected string $foo;
    protected int $bar;
    protected string $baz;
 
    public function __construct(string $foo, int $bar, string $baz) {
        $this->foo = $foo;
        $this->bar = $bar;
        $this->baz = $baz;
    }
}
 
$myFoo = new Foo('get', 1, 'life'); // Dealing with optional parameters and default values is not straight forward

class FooOptions { // Separate concerns into an options class that handles optional and default values...
    public string $foo;
    public int $bar = 1; // Optional, with default
    public string $baz;
}
 
class Foo { // And the main class that receives the options and handles some feature
    protected FooOptions $options;
 
    public function __construct(FooOptions $options) {
        $this->options = $options;
    }
}
 
$myFoo = new Foo((new FooOptions())->[ // Objects as argument bags smells like named parameters
    foo = 'get', // Parameter name and type checking
    baz = 'life',
]);

The fact that the assignments are executed in the order they are listed, just as if they had been specified on separate lines, has the following consequence:

$myObj->[
    foo = 10,
    bar = $myObj->foo + 20,
];
 
var_dump($myObj->bar); // int(30)

There may be arguments equally for and against this behavior, but ultimately the simplicity of the design and implementation wins, in my opinion.

Property names must be expressed literally. Some examples of what's possible in a regular assignment, but won't be allowed inside COPA:

$p = 'foo';
$myObj->$p = 'bar'; // Variable property name
$a->{"foo"} = 'baz'; // Property name generated from expression
 
$myObj->[
    $p = 'bar', // Syntax error
    {"foo"} = 'bar', // Syntax error
];

Supporting these expressions would probably be tricky to implement because the property names are not quoted, so they are not represented as literal strings, which makes them look like constants and complicates parsing in general, I believe. It also defeats the purpose of name and type checking, and is not a feature you'd miss in object literals either.

What follows is a handful of alternative ways to populate an object with existing syntax, and some hints of why it doesn't cut it:

class Foo {
	public int $bar;
	public int $baz;
}
 
$foo = new Foo(); 
$foo->bar = 1;
$foo->baz = 2;
 
doTheFoo($foo); // Cannot be done as an inline expression
 
// Oh yeah? What if I only need to set a single property?
doTheFoo((new Foo())->bar = 3); // Oops, fatal error: Can't use temporary expression in write context

/**
 * @method self setBar(int $bar) // Use annotations
 * @method self setBaz(int $baz) // Just repeating the properties
 */
class Foo {
	protected int $bar;
	protected int $baz;
 
        // This generic method could be injected using a trait
	public function __call(string $method, array $params): self {
		if (strpos($method, 'get') === 0) {
			$name = substr($method, 3);
			$this->$name = current($params);
		}
		return $this;
	}
}
 
doTheFoo((new Foo())
	->setBar(1)
	->setBar(2)
);

class Foo {
	public int $bar;
	public int $baz;
}
 
doTheFoo(new class extends Foo {
   public int $bar = 1; // Assigning values inline is now possible without creating setters!
   public int $baz = 2; // But I have to repeat their signature, which is annoying
 
   public function __construct() {
      $this->subFoo = (new Foo()) // And if I need expressions, I have to use the constructor
         ->setBar(3);
   }
}); // Pretty ugly, I'm afraid...

class Foo {
	public int $bar;
	public int $baz;
}
 
doTheFoo((function(){
   $foo = new Foo();
   $foo->bar = 1;
   $foo->baz = 2;
   return $foo;
})()); // Pretty good, if you can get those brackets straight... unless you need to use values from the outside scope :-(

This proposal is related to previous RFCs and shares motivation with them. However, there are distinctions and though COPA claims to be in the same family, here are some disclaimers:

This is not a way to write object literals using JavaScript Object Notation. It's similar to an array literal, but with each key actually corresponding to a defined property of the object. We don't want to quote the property names as there's no advantage, only added overhead. The equals sign is used straightforwardly to denote assignment. Square brackets have been chosen instead of curly ones because the latter already has an interpretation when following the object arrow, namely to create an expression which will return a property or method name.

• https://wiki.php.net/rfc/objectarrayliterals

I call this pseudo object literal notation because we're not writing the actual inner state of the object, we're merely populating properties after construction. But this syntax will allow you get benefits very similar to object literals in a simple, pragmatic way.

• https://wiki.php.net/rfc/object-initializer

Though on the wish list since 2013, named parameters have proved a tough nut to crack. But with this RFC you will be able to create parameter objects that may give you benefits very similar to named parameters when you pass it to a function that expects it.

• https://wiki.php.net/rfc/named_params
• https://wiki.php.net/rfc/simplified_named_params

None. Array followed by square bracket causes syntax error in PHP 7.4. This new syntax is optional. If you don't use it, your code will continue to run.

Next PHP 8.x

There are yet no patches nor tests. The question of who will be developing this will be addressed if the RFC passes.

After the project is implemented, this section should contain

1. the version(s) it was merged into
2. a link to the git commit(s)
3. a link to the PHP manual entry for the feature
4. a link to the language specification section (if any)

• https://wiki.php.net/rfc/object-initializer
• https://wiki.php.net/rfc/objectarrayliterals
• https://wiki.php.net/rfc/simplified_named_params
• https://wiki.php.net/rfc/named_params