Adrian's avatar

Adrián Martín

Adrian

Member since

62

Total Reputation

1

Total Arguments

19

Total Votes for Arguments

Arguments and votes

3

A breakthrough for language, easy to write easy to read.

Share:
Read the RFC: Short Closures 2.0 Adrian avatar
Adrian
voted yes
11

I'm not sure if allowing default implementations in interfaces is the way to go here.

To me it looks like a workaround / hack for non existing multi inheritance.

Why not either make multi inheritance possible instead or allow traits with interfaces as suggested by Victor?

Share:
Read the RFC: Interface Default Methods alexander avatar
alexander
voted no
12

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

Share:
Read the RFC: Short Closures 2.0 alexander avatar
alexander
voted yes
4

I really love short closure. JS solve this

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

This sounds like C++ Multi-Inheritence with extrasteps. Please don't.

Share:
Read the RFC: Interface Default Methods marko avatar
marko
voted no
13

I really do not want to see this in PHP because it tempts to apply closures on everything. The question is not if we can but if we should.

Share:
Read the RFC: Short Closures 2.0 marko avatar
marko
voted no
3

Classic closure is perfect for this kind of use case

Share:
Read the RFC: Short Closures 2.0 degraciamathieu avatar
degraciamathieu
voted yes
6

As with all other RFC with 'adding' behaviour, if you don't like it, just don't use it and left it for others :))

Share:
Read the RFC: Interface Default Methods arziel avatar
arziel
voted yes
43

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

Share:
Read the RFC: Interface Default Methods nabeel avatar
nabeel
voted no
8

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

Share:
Read the RFC: Short Closures 2.0 ricardo avatar
ricardo
voted yes
10

Technically writing a trait isn't a showstopper, but it adds cognitive load because the developer now must know/remember using this Interface requires adding this Trait. PHP should focus more on development experience!

Share:
Read the RFC: Interface Default Methods eugen avatar
eugen
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
5

I personally don't need it but I guess it could be useful to people.

Share:
Read the RFC: Interface Default Methods alex avatar
alex
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
17

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.

Share:
Read the RFC: Interface Default Methods marco avatar
marco
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
120

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
56
  1. Separation of what (interface) and how (class/trait)
  2. More balanced vote chart, now it's too green
Share:
Read the RFC: Interface Default Methods jacek avatar
jacek
voted no
40

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
RSS Feed Contribute Watch on YouTube Our License
© 2024 RFC Vote. This project is open source. Contribute and collaborate with us!