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
Anthony
I 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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
