[[Get]] and GetValue can return Reference Type

This issue is derived from Esprima issue 81 http://code.google.com/p/esprima/issues/detail?id=81 Hello everyone, According to the ECMA262 5.1th, [[Call]] of host object may return Reference Type. So, all values using raw [[Call]] result may be Reference Type. For example, [[Get]] may return Refe

Re: Error stack

2012/6/12 Brendan Eich > 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 privileged -- more t

Re: Error stack

On Mon, Jun 11, 2012 at 5:55 PM, Mark S. Miller wrote: > On Tue, Jun 12, 2012 at 7:59 AM, Charles Kendrick > 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 clarif

Re: Error stack

Mark S. Miller wrote: On Tue, Jun 12, 2012 at 7:38 AM, Brendan Eich 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. W

Re: Error stack

On Tue, Jun 12, 2012 at 7:59 AM, Charles Kendrick 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. --     Cheers,     --MarkM

Re: Error stack

On Mon, Jun 11, 2012 at 4:12 PM, Brendan Eich 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 > reimplemented u

Re: Error stack

On Mon, Jun 11, 2012 at 4:51 PM, Mark S. Miller wrote: > On Tue, Jun 12, 2012 at 7:38 AM, Brendan Eich wrote: >> I think Charles was arguing that anyone keeping secrets would need "use >> strict" to protect those secrets anyway, because otherwise >> arguments.caller.arguments[i] (given non-strict

Re: Error stack

On Tue, Jun 12, 2012 at 7:38 AM, Brendan Eich 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 think Charles was a

Re: Error stack

Mark S. Miller wrote: On Tue, Jun 12, 2012 at 7:12 AM, Brendan Eich 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. Maki

Re: Error stack

> 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 l

Re: Error stack

On Tue, Jun 12, 2012 at 7:12 AM, Brendan Eich 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 > arguments avai

Re: 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 compat

Re: Error stack

> 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.stac

Re: Error stack

Charles Kendrick wrote: On Sat, Jun 9, 2012 at 12:26 PM, Brendan Eich 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

Re: Function length

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 be

Re: Function length

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, the

Re: Error stack

On Sat, Jun 9, 2012 at 12:26 PM, Brendan Eich 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 frames. This is not a n

Re: Function length

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 fu

Re: Function length

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 works

Re: Function length

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 t

Re: Function length

> 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 'arg

Re: Why not NodeList#forEach :\?

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

Re: Add basic arithmetic to Math

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

Re: Why not NodeList#forEach :\?

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 http://wiki.ecmascript.org/doku.php?id=harmony

Re: Why not NodeList#forEach :\?

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 wrote: > > ES6 draft specifies a new Array constructor called Array.from that will >

Re: Why not NodeList#forEach :\?

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 wrote: > > > On Mon, Jun 11, 2012 at 9:09 AM, Tom Ellis wrote: > >> > ES6 draft specifies a new Array constructor called Array.from that w

Re: ecmascript 6 annotated available ?

Just came across that, thanks :) On Mon, Jun 11, 2012 at 7:17 PM, Rick Waldron wrote: > > > On Mon, Jun 11, 2012 at 6:59 AM, Hemanth H.M wrote: > > > The current spec draft is available here: > > http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts > > There are several formats, w

Re: Zed A. Shaw - The Web Will Die When OOP Dies

On Mon, Jun 11, 2012 at 8:54 AM, Hemanth H.M 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. Listen and learn,

Re: ecmascript 6 annotated available ?

On Mon, Jun 11, 2012 at 6:59 AM, Hemanth H.M 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 all are'* > h3mant

Re: Why not NodeList#forEach :\?

On Mon, Jun 11, 2012 at 9:09 AM, Tom Ellis 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 - Array.fro

Re: Why not NodeList#forEach :\?

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 Mo

Re: Why not NodeList#forEach :\?

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 *-- Hemanth HM * __

Re: Why not NodeList#forEach :\?

Le 11/06/2012 15:13, Hemanth H.M a écrit : 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 ? ( M

Re: Why not NodeList#forEach :\?

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 ma

Re: Why not NodeList#forEach :\?

> 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

Re: Why not NodeList#forEach :\?

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 Wal

Re: Why not NodeList#forEach :\?

Wow, that's interesting. When will that be implemented? On Mon, Jun 11, 2012 at 5:59 PM, Rick Waldron wrote: > > 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 a new Array con

Re: Zed A. Shaw - The Web Will Die When OOP Dies

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 in

Re: Zed A. Shaw - The Web Will Die When OOP Dies

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 a

Re: Function length

On 10 June 2012 03:52, Irakli Gozalishvili 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 function th

Re: Why not NodeList#forEach :\?

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 a new Array constructor called Array.from that will essentially convert "array-likes" into arrays: Array.from( nodes ).forEach

ecmascript 6 annotated available ?

-- *'I am what I am because of who we all are'* h3manth.com *-- Hemanth HM * ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Why not NodeList#forEach :\?

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 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

Re: Why not NodeList#forEach :\?

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: https://developer.mozilla.org/En/DOM/NodeList#Why_can%27t_I_use_forEach_or_map_

Why not NodeList#forEach :\?

[].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 *-- Hemanth HM * ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozi