(weighing in just as a developer...)
So this is pretty consistent with the language and would be easy to explain
to current and future developers:
// Short function, familiar rules:
() {
// ..
}
// Lexical this, tcp and all that
() => {
// ..
}
// Or
() => expr
Pipes are fine in and of themselves, but IMO you get something that looks
like a frankenstien language:
mtime: function() {
// use the proposed block syntax, `{ |args| }`.
this.withFile { |f|
// in block lambdas, +this+ is unchanged
var mtime = this.mtimeFor(f);
if (mtime < new Date() - 1000) {
// block lambdas return from their nearest function
return "too old";
}
sys.print(mtime);
}
},
"Fat arrows" are more aesthetically consistent and I feel like they will be
easier to explain:
mtime: function() {
// use fatty arrows
this.withFile((f) => {
// in block lambdas, +this+ is unchanged
var mtime = this.mtimeFor(f);
if (mtime < new Date() - 1000) {
// block lambdas return from their nearest function
return "too old";
});
sys.print(mtime);
});
},
just my opinion...
kevin
On Wed, Mar 7, 2012 at 2:54 PM, Brendan Eich <[email protected]> wrote:
> Gavin Barraclough wrote:
>
>> On Mar 7, 2012, at 8:35 AM, Rick Waldron wrote:
>>
>>> Honestly, I'm starting to believe that most nay-sayers would get over
>>> block-lambda looking weird at first and learn to really love the benefit it
>>> provides. Sure they might say "it looks really bizarre", but they will also
>>> say "remember when we had to assign var that = this; or use bind()? The
>>> dark ages!! I love block-lambda!"
>>>
>>
>> I think there are more valid criticisms than the bizarre look alone. The
>> block lambda syntax has the unintuitive restriction that only a subset of
>> expressions may be used in an initializer:
>> {|a = b&c| a} // valid
>> {|a = b&&c| a} // invalid
>> (This arises from the rule "BlockParameterInitialiser : =
>> BitwiseXorExpression", from http://wiki.ecmascript.org/**
>> doku.php?id=strawman:block_**lambda_revival<http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival>
>> ).
>>
>
> The obvious workaround: parenthesize. This is arguably small potatoes
> given parameter default values being new.
>
>
> Using '|' to wrap arguments is problematic, given its existing usage
>> within the language. There is a real advantages to a proposal that wrap
>> arguments in parentheses, such as "optional function" based ones on this
>> thread.
>>
> But (modulo separate "do" TCP proposal of yesterday) shorter function
> syntax is just syntax. No TCP, no lexical |this| in particular.
>
> Just replying to try to assign weights. The | vs. pdv issue is small IMHO.
> The incommensurate nature of block-lambdas vs. shorter functions hangs on
> TCP, which is big (bigger, anyway).
>
> /be
>
> ______________________________**_________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
