Daniel Sentker

not logical to remove them.

I don't think removing parenthese is a good idea

Even though this is a nice syntax that we also know from other programming languages, I think it is problematic. The reason for this lies in the ambiguity: How does the developer know whether $entity->setSlug() = '...' does something different than $entity->slug?

Without property hooks the case is quite clear: the setter method could still contain some "under-the-hood" steps (such as validation), while directly changing the property sets the value "unfiltered". It should stay that way.

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.

There is absolutely no need to mix interfaces with abstract classes. interfaces/contracts should not include any concrete implementation.

Another (extended) syntax for anonymous functions. We do not need to apply closures on everything.

No benefit, it is also feels bad to use a function name as string when referencing it. Limited usefulness if the via-string-called-function has more than one argument.

It's almost as messy as putting all the functions into each other.

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