Why can't lambda's be a simple case of a lexically scoped `return`
keyword with any arguments implicitly defined and accessible through a
predefined identifier/keyword (much like `arguments` works now)?
arr.map(return ''+arguments[0]+'
class='+this.getClassName(arguments[1])+'/');
arr.map(return
On Tue, Apr 17, 2012 at 2:33 AM, Peter van der Zee e...@qfox.nl wrote:
Why can't lambda's be a simple case of a lexically scoped `return`
keyword with any arguments implicitly defined and accessible through a
predefined identifier/keyword (much like `arguments` works now)?
arr.map(return
A few comments follow.
Addison
Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N WG)
Internationalization is not a feature.
It is an architecture.
On Mar 26, 2012 4:59 PM, Norbert Lindenberg
ecmascr...@norbertlindenberg.commailto:ecmascr...@norbertlindenberg.com
wrote:
Btw. I have full implementation (
http://code.google.com/p/v8-i18n/source/browse/#svn%2Fbranches%2Fglobalization)
of
the current spec (some items are missing, like best fit match, but that's
allowed by the spec). It's not yet in Chrome - we have to decide on the
namespace, to use Intl or v8Intl,
I kinda like it. My preferred being:
arr.map(return ''+$0+' class='+this.getClassName($1)+'/')
BTW, to respond to @TabAtkins, I know by experience that a very large amount
of lambdas have 'a', 'b', 'c', 'x', 'y' and 'z' as argument names, because
lambdas are short and have an obvious use.
François REMY wrote:
I kinda like it.
I don't, but what's more, Tab's point has come up already in TC39 in
similar settings. I doubt this will fly. It's hard to see 'return' in an
expression as different from 'return' at statement level. That's a
readability problem that I suspect would
I'm not sure if this has been discussed before, but is it a terribly bad
idea to make catch/finally optional for a try block?
There's a lot of code like this out there:
try { /* something here */ } catch (e) { /* nothing here */ }
Cheers,
Jussi
___
It's easy to forget to catch in cases you wanted to.
Maybe adding a new keyword:
try {
...
} drop;
17. април 2012. 13.35, Jussi Kalliokoski jussi.kallioko...@gmail.com је
написао/ла:
I'm not sure if this has been discussed before, but is it a terribly bad
idea to make catch/finally optional
Tangentially related: https://github.com/kriskowal/q/wiki/On-Exceptions
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Nebojša Ćirić [c...@google.com]
Sent: Tuesday, April 17, 2012 16:39
To: Jussi Kalliokoski
Cc: es-discuss
Brendan Eich wrote:
Irakli Gozalishvili wrote:
It would be amazing to have clojure like protocols in JS even
without `IFn`. I think it's very good feet and very useful in JS
where each library has it's own flavored API. I wrote more about it
here:
I don't think it's really necessary to have another keyword for that just
so you wouldn't forget the catch, sounds more like work for a static code
analysis tool to me, just like we don't want if (something) doSomething()
to throw just because you might have forgotten the curly braces.
P.S. Sorry
Brendan Eich wrote:
This last point is important: we do not want an object's typeof-type
to change by giving it a @call property. But we do want to enable call
and construct protocols to be built by users, by giving objects @call
and @construct properties.
I did not include an
+1 for simple enough. It's also shorter (12 vs 20)
On Tue, Apr 17, 2012 at 2:02 PM, Brendan Eich bren...@mozilla.org wrote:
Brendan Eich wrote:
This last point is important: we do not want an object's typeof-type to
change by giving it a @call property. But we do want to enable call and
It seems rather non-intention-revealing.
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Mark S. Miller [erig...@google.com]
Sent: Tuesday, April 17, 2012 17:20
To: Brendan Eich
Cc: Tom Van Cutsem; Mark Miller; es-discuss
On Tue, Apr 17, 2012 at 4:44 PM, Brendan Eich bren...@mozilla.org wrote:
Brendan Eich wrote:
Irakli Gozalishvili wrote:
It would be amazing to have clojure like protocols in JS even without
`IFn`. I think it's very good feet and very useful in JS where each library
has it's own flavored
Already specified by ES6 as patched by my mail ;-).
There's no fallback on @call from missing @construct. You have to say
what you mean. If you define @call and someone uses 'new', without an
inherited @construct you get a TypeError per 11.2.2 The new Operator.
/be
Russell Leggett wrote:
On Tue, Apr 17, 2012 at 10:11 PM, Brendan Eich bren...@mozilla.org wrote:
François REMY wrote:
I kinda like it.
I don't, but what's more, Tab's point has come up already in TC39 in similar
settings. I doubt this will fly. It's hard to see 'return' in an expression
as different from
Awesome. That gives you all the building blocks for trying out object exemplars
via a library.
I would add: [[HasInstance]] - @hasInstance
On Apr 17, 2012, at 22:44 , Brendan Eich wrote:
Brendan Eich wrote:
Irakli Gozalishvili wrote:
It would be amazing to have clojure like protocols in
On Tue, Apr 17, 2012 at 10:11 PM, Brendan Eich bren...@mozilla.org wrote:
... That's a readability problem
that I suspect would sink this if it were to get to TC39.
On the subject of readability; I believe that a worded keyword;
map(return $1+$2) gives a much stronger emphasis to HEY, I'M DOING
Peter van der Zee wrote:
On the subject of readability; I believe that a worded keyword;
map(return $1+$2) gives a much stronger emphasis to HEY, I'M DOING
FUNCTION STUFF OVER HERE than map((a,b)=a+b) would.
$1 and $2?
We may have to disagree on this one. I am telling you TC39 is not going
to
Axel Rauschmayer wrote:
I would add: [[HasInstance]] - @hasInstance
Yes, that one goes with @construct, and it seems safe to hook at
base-level because only instanceof uses [[HasInstance]].
As Mark and Tom argued in the Proxy design docs, stratifying in a new
proxy object is much safer
Brendan Eich wrote:
Let Clause 15.3.5 include new non-configurable, non-writable
properties of function objects named by @call and @construct (built-in
functions have only @call).
Allen points out that for self-hosting Date and the like (this came up
with the Intl work too, we think),
This is quite awesome. It seems like it might actually simplify a number of
things in the process.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Tue, Apr 17, 2012 at 7:06 PM, Brendan Eich bren...@mozilla.org wrote:
Axel Rauschmayer wrote:
I would add: [[HasInstance]] - @hasInstance
Yes, that one goes with @construct, and it seems safe to hook at
base-level because only instanceof uses [[HasInstance]].
As Mark and Tom argued in
Yeah, I don't like this and I would vote against this.
For the reasons already stated.
On Apr 17, 2012 3:24 PM, Brendan Eich bren...@mozilla.org wrote:
Peter van der Zee wrote:
On the subject of readability; I believe that a worded keyword;
map(return $1+$2) gives a much stronger emphasis to
25 matches
Mail list logo
