Den 2015-09-26 kl. 09:18, skrev Pavel Kouřil:
On Tue, Sep 22, 2015 at 3:59 AM, Bob Weinand <bobw...@hotmail.com> wrote:
Hey,
Thanks for all your feedback in the discussion thread!
So, before I start the vote, just two quick notes:
I've added two notes about the statement syntax and the single variable use.
Though a few people complained, I'm not switching to the ==> operator, as I
noticed many people expected typehints to work (they don't due to parser
limitations) when they compared to Hack's short Closures. It also allows us to
differ syntax-wise [e.g. for typehints] from Hack without causing any confusion
later. Which should be the smartest choice: Avoid conflicts. (If anyone strongly
feels against that, he may vote no, but I would like to not bikeshed that in this
Vote thread, but leave it free for eventual actual issues.)
Now, the link to the RFC about Short Closures:
https://wiki.php.net/rfc/short_closures
or straight ahead to the vote:
https://wiki.php.net/rfc/short_closures#vote
Thanks,
Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
since the RFC doesn't look like it will pass, I have a question about
RFC process - will you be able to "fix" the RFC and submit it for vote
again with targeting PHP 7.1?
The biggest issues seem to be
- ~> operator instead of ==>
- missing type hints
- auto imports
If probably the first two would be resolved, then maybe the RFC could
get accepted? I personally don't understand the 3rd complain, since
having to use() everything would make it "not-so-short closures".
I also remember people not liking the option not to have parenthesis
with single parameter. I was thinking about this, and with the type
hints, it would be probably better anyways to have the ( ) required,
so that would be just a single use case where they wouldn't be
required - so is there a point in keeping this special use case?
Regards
Pavel Kouřil
A good strategy. Suspect that fixing type hints & reach consensus
on auto import or not is enough to make it pass, maybe also
parenthesis.
I don't think ~> or ==> is cruical but then I personally favour ~>
because I find it more distinct, not confusing it with => or <=>.
Also having ==> might lead the thought that functionality is like
== vs ===. Hm... or if someday in the future comparison operator
without type juggling is needed.
Regards //Björn Larsson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php