Dustin Breuer

This RFC does not solve any issue, that cannot be solved right now with almost the same code, and makes the code harder to read. Beside this, this syntax invites developers to mix concerns.

• This syntax is in my opinion not really an advantage, especially with the hacky way to specify the callbacks (not even/especially not with the first class callable syntax).
• The argument positions are not consistent enough to support calls like this
• Passing additional arguments (like limiting the str_split, or specifying flags for htmlentities in the example) is not possible (or either will be really difficult to read, or will require to wrap it in arrow functions).

In classic PHP this is totally fine to read:

$input = 'Hello World';

$encoded = htmlentities($input, double_encode: false);
$list = str_split($encoded);
$uppercased = array_map(strtoupper(...), $list);
$result = array_filter($uppercased, fn($v) => $v !== '0'));

I don't understand "no" voters arguing about readability when use (...) is the one statement decreasing readability.

Voted "yes" because I think the opposite :

fn ($something) {
	return $somethingFromOuterScope . $something;
}

Is easy to read... $somethingFromOuterScope can not come from anywhere but only from the most close outer scope...

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

Moving to C# is not a good way IMHO. We will end with classes where properties are heavily mixed with the logic before actually we see class methods.

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.

I see no immediate benefit of the proposed solution over the userland implementations. The RFC mentions a shopping cart example, but I don't think that's cleaner than using league/pipeline or Laravel's pipeline.

It's a bit messy for the simpler examples as well.

The idea is a nice one, and one that I would welcome, but this proposal puts forward messy syntax that isn't clear!

At least once a week, I throw away an array_map because it ended up looking too bloated and go with a classic foreach instead. Short Closures 2.0 without the use(...) block would've solved this problem, just 2 votes...