[].forEach.call(NodeList,function(elm) {}) why that? Why not treat it like
an [] ?
--
*'I am what I am because of who we all are'*
h3manth.com http://www.h3manth.com
*-- Hemanth HM *
___
es-discuss mailing list
es-discuss@mozilla.org
Hi,
Le 11/06/2012 12:30, Hemanth H.M a écrit :
[].forEach.call(NodeList,function(elm) {}) why that? Why not treat it
like an [] ?
I've written a section on MDN specifically a while ago to answer that
very question:
Thank you very much for the clarification! Also noticed 'Extending the DOM
is dangerous.'
On Mon, Jun 11, 2012 at 4:16 PM, David Bruant bruan...@gmail.com wrote:
Hi,
Le 11/06/2012 12:30, Hemanth H.M a écrit :
[].forEach.call(NodeList,**function(elm) {}) why that? Why not treat it
like an
--
*'I am what I am because of who we all are'*
h3manth.com http://www.h3manth.com
*-- Hemanth HM *
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On 10 June 2012 03:52, Irakli Gozalishvili rfo...@gmail.com wrote:
I just noticed strange behavior in spider monkey implementation of rest
arguments:
(function(a, b, ...rest) {}).length // = 2
I think ignoring `rest` in length is pretty counter intuitive. For example I
have small utility
Hi,
I'm wondering what's the point of posting just a video like this. Do you
have specific needs? Are there issues you want to discuss?
We all want sugar. I came to es-discuss as a developer (which I still
am) and I wish there was more sugar and that's in part what is being
discussed here on
Well, I came looking for sugar, was reading few of the proposal which
already covers my needs, will update as soon as I get anything either than
those in the proposal.
/me understands that just a video link is too very wage, but, felt it made
few strong suggestions.
How can one contribute ( as
Wow, that's interesting. When will that be implemented?
On Mon, Jun 11, 2012 at 5:59 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Monday, June 11, 2012 at 6:30 AM, Hemanth H.M wrote:
[].forEach.call(NodeList,function(elm) {}) why that? Why not treat it like
an [] ?
ES6 draft specifies
Le 11/06/2012 14:56, Hemanth H.M a écrit :
Wow, that's interesting. When will that be implemented?
Depends on browsers. Good news is that you can polyfill it today! :-)
Actually, that could be a good fit for https://github.com/paulmillr/es6-shim
David
On Mon, Jun 11, 2012 at 5:59 PM, Rick
ES6 draft specifies a new Array constructor called Array.from that will
essentially convert array-likes into arrays
This will have uses for the arguments objects too, for people that aren't using
...rest in ES6.
Tom
___
es-discuss mailing list
Uber kool! Thanks a ton David!
npm install es6-shim # wow :) Shall blog about this!
Well, Map() and Set() is already there is FF13, it's an experimental API
right? Experimental means it can be chucked off or it shall be modified
drastically ? ( More Java like APIs :\ )
Well {} behaved liked
Ha Hmm, yet to iterate sets.
On Mon, Jun 11, 2012 at 6:48 PM, David Bruant bruan...@gmail.com wrote:
http://productforums.google.com/forum/#!topic/docs/0hQWeOvCcHU
--
*'I am what I am because of who we all are'*
h3manth.com http://www.h3manth.com
*-- Hemanth HM *
Le 11/06/2012 15:23, Hemanth H.M a écrit :
Ha Hmm, yet to |iterate| sets
For...of loop may be of some help here. Good introductory article by
Axel Rauschmayer from this morning (doesn't talk about Sets, but it
should work I think): http://www.2ality.com/2012/06/for-of-ff13.html
David
On
On Mon, Jun 11, 2012 at 9:09 AM, Tom Ellis tellis...@gmail.com wrote:
ES6 draft specifies a new Array constructor called Array.from that will
essentially convert array-likes into arrays
This will have uses for the arguments objects too, for people that aren't
using ...rest in ES6.
Indeed
On Mon, Jun 11, 2012 at 6:59 AM, Hemanth H.M hemanth...@gmail.com wrote:
The current spec draft is available here:
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
There are several formats, with and without change notations
Rick
--
*'I am what I am because of who we
On Mon, Jun 11, 2012 at 8:54 AM, Hemanth H.M hemanth...@gmail.com wrote:
snip
How can one contribute ( as in code to ES or Javascript ) ?
It's been my immediate, personal experience that participation itself is
the best form of contribution. Be thoughtful, do research, think
critically, etc.
Just came across that, thanks :)
On Mon, Jun 11, 2012 at 7:17 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Mon, Jun 11, 2012 at 6:59 AM, Hemanth H.M hemanth...@gmail.com wrote:
The current spec draft is available here:
Thank you Rick Waldron :)
BTW tired 'es6-shim' on node.js and :
Math.sign(-0)
-1
Should it give an error?
On Mon, Jun 11, 2012 at 7:14 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Mon, Jun 11, 2012 at 9:09 AM, Tom Ellis tellis...@gmail.com wrote:
ES6 draft specifies a new Array
Awesome. I've had es6-shim for a while now but I haven't used it yet. I forgot
what its use was until now.
Tom
On 11 Jun 2012, at 14:44, Rick Waldron wrote:
On Mon, Jun 11, 2012 at 9:09 AM, Tom Ellis tellis...@gmail.com wrote:
ES6 draft specifies a new Array constructor called
On Jun 11, 2012, at 7:00 AM, Hemanth H.M wrote:
Thank you Rick Waldron :)
BTW tired 'es6-shim' on node.js and :
Math.sign(-0)
-1
Should it give an error?
You could find the answer to that by checking the draft specification at
On Jun 10, 2012, at 11:48 AM, Angus Croll wrote:
Rationale:
Some functional JavaScript idioms are hamstrung by the lack of native basic
arithmetic functions.
Would be handy/elegant/instructive to be able to write
arr.reduce(Math.add);
Moreover having functional versions of
Not quite impossible, you just have to get a bit creative. While certainly
not as fast as a built in implementation, the method used here is still
O(1). https://github.com/Benvie/ES6-Harmony-Collections-Shim
The major use case for Maps and Sets (as far as i'm concerned) is the
ability to use
I don't think any library should ever rely on f.length.
That's a wrong attitude, there always will be legitimate uses of any feature,
otherwise such features are just harmful IMO should be deprecated / removed.
It is not a
reliable source of information (f might use
On Jun 11, 2012, at 10:56 AM, Irakli Gozalishvili wrote:
I don't think any library should ever rely on f.length.
That's a wrong attitude, there always will be legitimate uses of any
feature, otherwise such features are just harmful IMO should be deprecated
/ removed.
Let me try
I would not mind removing Function 'length' but on the web you cannot
deprecate and any browser daring to remove will appear broken to users
not involved in the content or the engine, and users switch browsers.
Anyway, back to reality: foo.length is in ECMA-262 and we need to spec
how it
Sorry for not being clear about this. Here is a simplified example of the
implementation:
https://gist.github.com/2911817
Also this is just a single particular example, but I expect there to be more. I
think what I'm
really asking for is a way to know if …rest is being used.
Also IMO arrow
On Sat, Jun 9, 2012 at 12:26 PM, Brendan Eich bren...@mozilla.org wrote:
We do not want a
non-debugger API that works only some of the time.
What we want (IMO) is an API that allows runtime diagnostics to be collected.
By necessity, function arguments would be unavailable for some stack
I find Function 'length' as very useful property (I use it in some low-level
functional stuff). I also think that defining functions so it reflects only
required arguments is very sane decision. In that light I would also expect
...rest to not be counted in Function length.
+1 for keeping it,
Irakli Gozalishvili wrote:
Sorry for not being clear about this. Here is a simplified example of
the implementation:
https://gist.github.com/2911817
Also this is just a single particular example, but I expect there to
be more. I think what I'm
really asking for is a way to know if …rest is
Charles Kendrick wrote:
On Sat, Jun 9, 2012 at 12:26 PM, Brendan Eichbren...@mozilla.org wrote:
We do not want a
non-debugger API that works only some of the time.
What we want (IMO) is an API that allows runtime diagnostics to be collected.
By necessity, function arguments would be
It seems to me we've lost the thread (maybe you haven't, but I have --
apologies for revisiting).
In a nutshell, I'm looking for access to function arguments, the
receiver, and ideally even local variable values via *some* runtime
diagnostic API.
These could be all be exposed in an error.stack
I have a sinking feeling it may be better to do just error.stackFrames,
the new object/number/string lazy stack-trace reflection. We can model
it on the union of error.stack implementations in the field, so those
could be reimplemented under/on-top-of error.stackFrames. But we'll have
no
On Tue, Jun 12, 2012 at 7:12 AM, Brendan Eich bren...@mozilla.org wrote:
Your point about not violating use strict or elaborating too much is good,
but I want to push back on one thing: local vars may be a bridge too far,
especially with optimizing JITs, block-scoped let bindings, etc. Making
Your point about not violating use strict or elaborating too much is good,
but I want to push back on one thing: local vars may be a bridge too far,
especially with optimizing JITs, block-scoped let bindings, etc. Making
arguments available is easier.
I definitely recognize that making local
On Tue, Jun 12, 2012 at 7:38 AM, Brendan Eich bren...@mozilla.org wrote:
Also, as you pointed out, even error.stack leaks information. Where do you
draw the line?
Conservatively. I suggest that there be no error.stack, but rather
getStack(error), in order to avoid this information leak.
I
On Mon, Jun 11, 2012 at 4:51 PM, Mark S. Miller erig...@google.com wrote:
On Tue, Jun 12, 2012 at 7:38 AM, Brendan Eich bren...@mozilla.org wrote:
I think Charles was arguing that anyone keeping secrets would need use
strict to protect those secrets anyway, because otherwise
On Mon, Jun 11, 2012 at 4:12 PM, Brendan Eich bren...@mozilla.org wrote:
I have a sinking feeling it may be better to do just error.stackFrames, the
new object/number/string lazy stack-trace reflection. We can model it on the
union of error.stack implementations in the field, so those could be
On Tue, Jun 12, 2012 at 7:59 AM, Charles Kendrick
char...@isomorphic.com wrote:
I'm reading this as saying that stack traces in general should not be
available unless the code is privileged in some way. This can't be
what you mean, so could you clarify?
That is exactly what I mean.
--
Mark S. Miller wrote:
On Tue, Jun 12, 2012 at 7:38 AM, Brendan Eichbren...@mozilla.org wrote:
Also, as you pointed out, even error.stack leaks information. Where do you
draw the line?
Conservatively. I suggest that there be no error.stack, but rather
getStack(error), in order to avoid this
On Mon, Jun 11, 2012 at 5:55 PM, Mark S. Miller erig...@google.com wrote:
On Tue, Jun 12, 2012 at 7:59 AM, Charles Kendrick
char...@isomorphic.com wrote:
I'm reading this as saying that stack traces in general should not be
available unless the code is privileged in some way. This can't be
2012/6/12 Brendan Eich bren...@mozilla.org
I see -- thanks. We should try to detail the privileged APIs and their
module(s) a bit more. I used @reflect above but I didn't mean to equate
it to Tom's Reflect.* used in conjunction with direct proxies. And not all
reflection facilities are
41 matches
Mail list logo
