bronek89's avatar

Bronisław Białek

bronek89

Member since

95

Total Reputation

2

Total Arguments

11

Total Votes for Arguments

Arguments and votes

1

It will make php more consistent

Share:
Read the RFC: Short Closures 2.0 bronek89 avatar
bronek89
voted yes
3

It could be nice addition to creating DTOs objects in PHP with "virtual" properties:

readonly final class SomeDto
{
    public function __construct(
        public string $name,
        public string $surname,
        public string $fullName {
            get => ucfirst($this->name) . ' ' . ucfirst($this->surname);
        }
    ) {
    }
}

or even shorter version:

readonly final class SomeDto
{
    public function __construct(
        public string $name,
        public string $surname,
        public string $fullName => ucfirst($this->name) . ' ' . ucfirst($this->surname),
    ) {
    }
}
Share:
Read the RFC: Property Hooks bronek89 avatar
bronek89
voted yes
9

Thanks to readonly properties, I started relying more and more on properties alone. However, I actually often find the need for more fine-grained control over input and output, but adding methods feels so heavy-weight. Property hooks feels like the perfect solution for some of my use cases.

Share:
Read the RFC: Property Hooks Contributor brent avatar
brent
voted yes
17

In combination with Asymmetric visibility this will allow to replace all getters and setters with trivial properties and occasional hooks.

Share:
Read the RFC: Property Hooks pronskiy avatar
pronskiy
voted yes
25

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.

Share:
Read the RFC: Property Hooks maz avatar
maz
voted yes
23

For example:

$result = "Hello World"
    |> 'htmlentities'
    |> 'str_split'
    |> fn($x) => array_map('strtoupper', $x)
    |> fn($x) => array_filter($x, fn($v) => $v != 'O');

Is 'nicer' since it has better readability and clearer syntax than:

$result = array_filter(
        str_split(
            strtoupper(
                htmlentities("Hello World")
            )
        ),
        fn($v) => $v != '0'
    );
Share:
Read the RFC: The Pipe Operator josebenraul avatar
josebenraul
voted yes
82

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
64

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:

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:

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.

Share:
Read the RFC: The Pipe Operator Contributor brent avatar
brent
voted yes
39

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

Share:
Read the RFC: Short Closures 2.0 eugen avatar
eugen
voted yes
81

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.

Share:
Read the RFC: Short Closures 2.0 marco avatar
marco
voted yes
121

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

Share:
Read the RFC: Short Closures 2.0 davi avatar
davi
voted yes
RSS Feed Contribute Watch on YouTube Our License
© 2024 RFC Vote. This project is open source. Contribute and collaborate with us!