Takayasu Oyama

Often, I add static methods to some classes in order to improve readability when I instantiate a new class; the ability of chaining methods directly to the constructor, without the unnecessary parenthesis boilerplate, would remove the need for that.

This is good to have.

Properties are useful for exchanging (reading and writing) single values. Properties are good for data binding, etc.

With this RFC we can implement:

• Validation
• Trigger events
• Call methods if there is more to do

Update: About the $field I am not sure. Having a separate backing field can have some advantages.

For me, the most important argument is that the pipeline pattern is a tried and tested pattern, that this RFC builds upon. A couple of examples:

• league/pipeline
• laravel's pipeline

This RFC adds syntax to make using these kinds of pattern much more convenient.

On top of that, there's the argument that multiple modern languages support a pipe operator:

• Hack
• Haskall
• Ruby
• Elixir
• And more

Finally, I've had numerous occasions where a pipe operator would simplify my own code — I have more than a handful real life cases where this would be useful.

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

Either this, or something like a use(*) would make the code easier to read and write. Makes sense to me. All major languages has this feature. I don't understand the push back from the core team.

It improves the readability and usability of closures that consist of more than one assignment.

Just look at how other languages solve this. C# for example. Make short closures like that.

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

Creating traits for default implementation is just a pain. I want syntactic sugar

I wrote down some thoughts on this RFC on my blog. I think it's worth rethinking our current definition of what "an interface" is. Especially since many languages are interface default methods as their way of multi-inheritance.