(Slightly off topic...) In Yehuda Katz's examples (one of which I quoted) he's doing synchronous file stuff. Which we don't really do in javascript. Since so much of the code we write is asynchronous it seems like TCP return semantics are not really applicable. Or are they?
Thanks, kevin On Wed, Mar 7, 2012 at 8:31 PM, Kevin Smith <[email protected]> wrote: > (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
