On Dec 7, 2008, at 11:43 PM, Michael Day wrote:
Hi Brendan,
I say 1 trumps 2 for the reason given in the last paragraph: human
programmers first, meaning the fat bell curve (sorry, Schemers).
I agree with this; there are all sorts of clever things that
implementors can do that don't necessarily need to be exposed as
features in the language standard.
However, as Eugene Lazutkin pointed out, is omitting 'this' and
'arguments' a sufficiently compelling improvement to justify
introducing a whole new language construct?
I believe this is Waldemar's view too, which along with his objection
to the completion-value hazard leads to the "improve functions through
strict mode or a new version" approach.
There's a lesser goal I didn't list: make function syntax thinner.
'function' is eight whole letters, plus four chars of parens and
braces, plus 'return'. Wherefore expression closures in JS1.8 -- they
save the braces and 'return' overhead. But to fix expression closures
to be bottom-up unambiguous we would require at least parens around
the body-expression.
More concise function syntax is not a goal solely, or even
exclusively, to support user-defined control abstractions. It's a good
in its own right unless you consider every use of a function
expression in JS today to be a control abstraction in the Smalltalk
block sense (I do not).
In some cases in strict mode 'this' will be undefined instead of
being the global object, does this come close enough to omitting
'this' for functions which are not methods?
Not really -- strict mode does not change the ability of |this| to be
rebound in the absence of Function.prototype.bind usage, which has its
costs, and which apart from overhead in implementation terms, takes
too long to say in the language to be likely as a default practice.
Sure, Ajax libraries use it well, but it's still observed more in the
breach looking at the whole of "web JS".
/be
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
