sandermuller's avatar

Sander Muller

sandermuller

Member since

100

Total Reputation

4

Total Arguments

10

Total Votes for Arguments

Arguments and votes

1

Even if you won't use this yourselve, it will allow libraries and frameworks to do some really cool stuff. LGTM!

Share:
Read the RFC: Property Hooks sandermuller avatar
sandermuller
voted yes
1

Neat with first class callable syntax

Share:
Read the RFC: The Pipe Operator sandermuller avatar
sandermuller
voted yes
1

Small but nice QoL improvement

Share:
Read the RFC: Short Closures 2.0 sandermuller avatar
sandermuller
voted yes
2

Prevents having to add a trait to every class that has to implement an interface, being able to provide default implementations via interfaces would be a large DX improvment

Share:
Read the RFC: Interface Default Methods sandermuller avatar
sandermuller
voted yes
11

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')
        )
    )
);
Share:
Read the RFC: The Pipe Operator moebrowne avatar
moebrowne
voted yes
83

With First-class callable syntax available since 8.1, it would now be possible to write it as below, which is much better then string names of functions:

$result = "Hello World"
    |> htmlentities(...)
    |> str_split(...)
    |> fn($x) => array_map(strtoupper(...), $x)
    |> fn($x) => array_filter($x, fn($v) => $v != 'O');
Share:
Read the RFC: The Pipe Operator pronskiy avatar
pronskiy
voted yes
22

I could have used it multiple times for array transformations. But the RFC still built on really ancient PHP behaviour (mapping functions as strings) and should be redone by fosucing only on modern syntax:

  • closures and short closure: |> fn($x) => array_filter($x, fn($v) => $v != 'O')
  • first class callable syntax: |> str_split(...)
Share:
Read the RFC: The Pipe Operator tpetry avatar
tpetry
voted yes
8

It will solve having to create traits to add a default implementation when creating interfaces and keeping it nicely together improving the DX

Share:
Read the RFC: Interface Default Methods Carakas avatar
Carakas
voted yes
39

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

Share:
Read the RFC: Interface Default Methods marc avatar
marc
voted yes
55

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.

Share:
Read the RFC: Interface Default Methods Contributor brent avatar
brent
voted yes
RSS Feed Contribute Watch on YouTube Our License
© 2024 RFC Vote. This project is open source. Contribute and collaborate with us!