ju5t

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.

Still hard to read. No extra benefits.

The only clean solution is to use scalar types (string, int, float, boolean) and arrays like objects:

$result = "Hello World"->htmlentities()->split()->map(strtoupper(...))->filter(fn($v) => $v != 'O');

Chain, clean oop, readable, IDE hint, no value parameter, no prefixes and an opportunity to correct the functions inconsistency. It could works beside functions: strtoupper($name) and $name->toUpper().

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!

It looks pretty much the exact function as abstract class. I still think interfaces/contracts should not include any concrete implementation

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...