sezghin314@gmail.com

this allows for cleaner code. less verbose.

Initially I had exact the same opinion as other folks voting no: "Separation of ..." , "Interface must not include ...".

Reading this internals.io thread which I highly recommend to read I realized that yes, these arguments were drilled in me in university times.

Second, the more I read about traits the more I understand that it drags down modern PHP as a language, being just "copy paste" code. So I think traits in general must be discouraged to be used in situations they don't fit.(Saying this because see some folks really abusing traits).

Third I discussed with my C# colleagues and they all like default methods as feature, which makes me think, its not that bad.

I think complaints about the syntax being messy are really about the array manipulation functions being inherently hard to format nicely.

To be clear I agree that the proposed example isn't great, nested closures are never going to win any readabillity prizes. If however we look at any non-array based manipulation I think the readabillity is objectively better:

$name = 'my_user_name'
    |> fn (string $string): string => str_replace('_', ' ', $string)
    |> strtolower(...)
    |> ucwords(...)
    |> trim(...);

Or without first class callables:

$name = 'my_user_name'
    |> fn (string $string): string => str_replace('_', ' ', $string)
    |> fn (string $string): string => strtolower($string)
    |> fn (string $string): string => ucwords($string)
    |> fn (string $string): string => trim($string);

Bonus: this also adds runtime type checks to each step. Eg strreplace returns string|array

I can't imagine anyone would think this is better:

$name = trim(
    ucwords(
        strtolower(
            str_replace('_', ' ', 'my_user_name')
        )
    )
);

Multi-inheritance seems to be the hot topic that prevented this RFC from being approved even though it was not the RFC target. Multi-inheritance is an afterthought that may or may not be abused with this change. What we want would actually be just the convenience of doing what Traits already allow while reducing potential BC break impact coming from interface changes. There are interfaces originated from the interface segregation mindset that often has only 1 implementation and could very well take advantage of default implementation for a simpler system design.

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