Re: Re: [RFC] [Discussion] Short Closures
| From: | Rowan Collins | Date: | Mon, 07 Sep 2015 10:38:42 +0000 |
| Subject: | Re: Re: [RFC] [Discussion] Short Closures | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-88087@lists.php.net to get a copy of this message | ||
Anthony Ferrara wrote on 07/09/2015 11:23:
Being completely fair, doesn't this actually make HackLang a great test-bed for PHP features? If they implement something, and people hate it/it sucks, boom. But if people love it, it's a no brainer for us to "steal". I don't think we should blindly accept anything because it's in hack, but the fact that it's there means we also shouldn't diverge "just because". If it makes sense to copy it, why not? The one thing I think we absolutely MUST avoid is changing behaviour slightly but keeping same syntax. For example, if we used ==> for short closures but used a different semantic. That would be *really* bad. That leaves us with either taking their semantics whole sale for the feature, or creating our own syntax. That's what Bob has proposed here. Overall, I think we should steal outright what makes sense (I use steal weakly here, it's collaborative). We should take inspiration where it makes sense, and we should forge our own road where it makes sense. I have not a single ounce of reservation about "giving authors of Hack a disproportionate influence on PHP". They are not being given a blank check, no more than any other contributor is. But we also shouldn't be stupid and ignore what they are doing because of pride (or whatever else). My $0.02 AnthonyI agree 100% with this; you've put it much better than I did. The only additional scenario I can see is where Hack's initial definition of a feature has some problem, and rather than copying that problem into PHP, we might fix it and leave Hack to do the same when their process allows (I don't know what the BC policy on Hack is). That would be an exception where keeping syntax but varying semantics *might* make sense, if the communication between teams was clear that the semantics would be realigned later. Regards, -- Rowan Collins [IMSoP]