Nathan

An interface is a contract, that should define what the behaviour of an object is. If you need default methods, use an abstract class that implements said interface. If you require more than one abstract class, you can use traits, or your class structure is probably wrong

I like the concept but not the operator. As one of the other commenters said, it would be better if all the scaler

I find myself reaching for foreach, while, and for loops, to do things that PHP already provided in functions, simply because using arrow functions would look too messy.

I do believe this has merit and uses cases, but I agree that value objects would cover this better and there are other things the developers could put their time towards

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.

While I'm not against the concept in general, this implementation is not well-done. The $value variables comes from nowhere and makes it confusing - it looks like an undefined variable and a quick glance at it, was the first thing I thought - where is $value coming from? Why not just use $name within that block? Same with $field? Why not just return the value that is going to be set? This is one of the more confusing RFCs I've seen and does not follow the PHP-code style, makes things confusing for both new and experienced coders. In it's current format, I can't approve with good conscience.

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'm not sure if allowing default implementations in interfaces is the way to go here.

To me it looks like a workaround / hack for non existing multi inheritance.

Why not either make multi inheritance possible instead or allow traits with interfaces as suggested by Victor?

• Interface shall stay light, pure contracts defining expectations, else they are just abstract classes with multi-inheritance.
• If multi-inheritance is the subject, a specific RFC shall be done on this.
• An other away might be to dig back this RFC to add interface to traits: https://wiki.php.net/rfc/traits-with-interfaces

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

PHP is evolving. There are new concepts added to many programming languages to ease writing and reading (more important!). PHP should focus more on developer experience (but not for legacy projects that get never upgraded to PHP 8+).

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.

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