This is last draft from Brendan Eich:
FunctionDeclaration:
function Identifier ( FormalParameterList_opt ) { FunctionBody }
Identifier ( FormalParameterList_opt ) [no LineTerminator here] { FunctionBody }
ShortFunctionExpression:
Identifier_opt ( FormalParameterList_opt ) [no LineTerminator here] { FunctionBody }
Identifier_opt ( FormalParameterList_opt ) => InitialValue
I'm @qconlondon waiting for the next talk so I decided to take a couple of minutes to blog about this little experiment.
In ES-Discuss developers are still talking about function keyword, if it's needed or not.
I believe the fact CoffeeScript has no explicit function is one of the major reasons devs have been attracted so I made it even simpler.
Just Drop The Function
With current ES 3, 5, or 5.1 syntax I can't really see problems or ambiguity removing that keyword but if you find a case that could fail please let me know.Of course if we use a keyword we should be able to understand the difference, i.e. with for, if, or others, and this simple test page is just an experiment: you write some code, you "functionize" it, and if the code does not run it's showed highlighted in red.
The RegExp is quite simple and straight forward and parsing time should never be a problem even for big projects.
The return is implicit, a bit Ruby style, but of course you can chose to return in the middle of a function.
Thing is, the very last statement will be returned and you can play with results.
I wonder if anyone would use such syntax on daily JavaScript coding. The parser needs improvements in any case so just think about it and let me know. Cheers
9 comments:
eval("h = () { alert('hello'); }");
I like that!
I tested the "reverse functionize" you provided me on twitter, on a few hundred lines of code it still reads perfectly.
If anyone wants it, written WebReflection style:
unFunctionize(code) {
code.replace(/\b(?:function|return)\b/g, "");
}
For the "return" part, if I remember correctly my C programming 101, C language does exactly the same if return is omitted.
It can lead to surprises in "if" syntaxes function calls though.
Nice work Andrea.
I can see the value of dropping the function keyword in compressed code but for development I think the use of the keyword greatly enhances readability
seems that the implicit return breaks down when using statements, e.g.
(x) {if (x==1){return 1}}
But yeah, it would be nice if it worked in the general case.
riffraf ... what about (x) {x==1 ? 1 : null} ? But I agree this concept should not change the way developers code
eval won't work as well as it doesn't if you don't parse runtime, as example, CoffeeScript syntax
I'm against dropping the function keyword (at least not without it being replaced by something that's equally recognizable as "look here, I'm creating a new function now!").
I don't mind making the return implicit, but would still like to have the option to do so explicitly. I guess the return keyword is not going away anyways because that would break a lot of code (early returns).
The main reason I don't like this shorter notation bullshit is that it makes code far less readable while the proposed gain (less typing) is still an argument I can't grok.
You type function faster than you speak it. You can't tell me that really bothers you in your every day coding. I won't believe it.
I basically agree with you but a about the return, as it is implicit in Ruby, with the possibility to return in the middle with explicit one, I think could make sense.
As you can see in the example page, the coolest part is for inline, single operation, shortcut where at least there, arr.filter((a){a x < NUM could be one of these
Yeah I agree, it totally makes sense for lambda expressions. I actually got swayed to the `arr.map({|a,b| log(a,b); })` syntax with the Ruby vs JS post (http://agentcooper.github.com/js-ruby-comparison/).
Post a Comment