Feature Request: Enhanced Syntax for Property Declarations...

[DxBang]

I would like to request the addition of a syntax feature in PHP that allows grouping multiple properties with the same type in a class, improving code readability and reducing repetition in class definitions. This feature would be similar to the ability to declare properties in a single line with type hints introduced in PHP 7.4, but with the added flexibility to group them logically by type.

For a long time we have been able to do:

class SimplePlural {
	private
		$name = 'Plural',  // separate by commas
		$value = 0,
		$isTrue = false,
		$array = [],
		$object,
		$noType;
}

As long as we didn't give it a typed property, but since 7.4 we had to declare the visibility modifiers every time if we wanted to have typed properties on them.

class Singular {
	private string $name = 'Singular';
	private int $value = 0;
	private bool $isTrue = false;
	protected array $array = [];
	protected object $object;
	protected $noType;
}

The Proposal

Grouped Property Declarations with Type Hints

PHP currently supports declaring properties either with type hints introduced in PHP 7.4 or without type hints using a grouped style. However, a hybrid syntax combining both would simplify code readability and maintenance.

A mixture of both.

class Plural {
	private
		string $name = 'Plural',  // separate by commas
		int $value = 0,
		bool $isTrue = false;
	protected
		array $array = [],
		object $object,
		$noType;
}

A bit similar to, but without the type grouping.

class Series {
	private string
		$n = 'Se', // separate by commas
		$m = 'ri',
		$s = 'es';
	private int
		$v = 0,
		$u = 1,
		$e = 2;
	private bool
		$t = true,
		$f = false;
	private array
		$a = [],
		$r = [1, 2, 3];
	private object
		$o,
		$b;
}

Benefits:
Improved readability: Grouping related properties by type would make class definitions easier to scan, especially in larger classes.
Reduced repetition: Reduces the need to repeat the type declaration for each property, making the code more concise.
Better maintainability: It's easier to spot and manage changes for properties that share the same type.

And it would also be nice if we could create simple JSON-like objects directly instead of building them in __construct() and why not allow { } to create objects instead of (object) [ ]? It is something we are used to from JSON.

Thanks and happy coding!

[iluuu1994]

Hi @DxBang. I don't understand, this is already how it works (minus the JSON thing). https://3v4l.org/Yu7nk

[DxBang]

Hi @DxBang. I don't understand, this is already how it works (minus the JSON thing). https://3v4l.org/Yu7nk

Ah, yes, that one works, I just didn't read the error message correctly when I was testing it... I had 2 $a, DU'H!! I will remove part 2, thanks :)

[cmb69]

And it would also be nice if we could create simple JSON-like objects directly instead of building them in __construct() and why not allow { } to create objects instead of (object) [ ]? It is something we are used to from JSON.

See https://wiki.php.net/rfc/compact-object-property-assignment, for prior art.

I have no particular opinion on the the visibility grouping proposal.

In any way, this requires the RFC process.

[iluuu1994]

@DxBang

class Plural {
	protected
		array $array = [],
		object $object,
		$noType;
}

This clashes with your other suggestion. How do we know if $noType is a continuation of $object and hence is also of type object, or new list section of properties with no types?

I'm pretty sure there have also been proposals for adding the {} syntax in the past (you may be able to find them on https://externals.io/). I don't see a big point. stdClass is not something I believe should be encouraged. You're better off using arrays, which is what stdClass uses under the hood anyway. They are also already supported in property initializers.

[github-actions]

There has not been any recent activity in this feature request. It will automatically be closed in 14 days if no further action is taken. Please see https://github.com/probot/stale#is-closing-stale-issues-really-a-good-idea to understand why we auto-close stale feature requests.