Ruslan Popelyshyn

There are some arguments against the implementation and I agree to those. But in addition I don't agree to the concept itself, personally, because I am convinced that immutability is key when enforcing domain logic. E.g. the example above could be replaced by:

readonly class User {
		public function __construct(public string $name) {
				if (strlen($name) === 0) {
						throw new ValueError('Name must be non-empty');
				}
		}

		public function withName(string $newName): self {
				return new self($newName);
		}
}

Or, even better IMO, with value objects that validate themselves:

readonly class User {
		public function __construct(public Name $name) {}

		public function withName(Name $newName): self {
				return new self($newName);
		}
}

readonly class Name {
		public function __construct(public string $value) {
				if (strlen($value) === 0) {
						throw new ValueError('Name must be non-empty');
				}
		}
}

Granted, this is only one example and immutabilty is not a silver-bullet. But I haven't come across a usecase for property hooks that was really convincing yet

This kind of code looks very appealing when performing very simple (and anemic) CRUD operations on a model, but it has a very short trajectory when the code gets a little more complex.

Triggering events is shown as an example of an advantage of this feature, but it's clearly a bad idea: https://3v4l.org/ZCVpG#v8.2.11

Also, if you need a centralized validation around an attribute, a value object is a way better option: https://3v4l.org/QWm8c#v8.2.11

I think that there are a ton of better requests with a lot more of value to achieve this in userland code.

Also, this idea is very overlooked, and would require a lot of internals work after to cover all the edge cases. How should child classes behave? Are they overridable? How do you know if there is a setter behavior defined already? How should traits behave? Is there a way to call the parent class setter/getter? Would that be overriden or just called by default?

Also, in response to some comments:

It could be used by ORMs like Laravel Eloquent Model that has cast and other hooks to transform data on get/set.

Good ORMs should provide mechanisms for this!

However, I actually often find the need for more fine-grained control over input and output, but adding methods feels so heavy-weight.

This is the perfect case for value objects to kick in. You want behavior (input validation, output transformation maybe) at an atomic member, that could be exactly this but atomically standalone, and therefore reusable in other cases, and very easily testable.

it will increase code readability to sky)

We spend a lot more time reading code than writing it. The elegance of short closure combined with the convenience of variable scope usage has already shown to be a game changer on Typescript and there doesn’t seem to be any technical issue with having it on PHP.