Merry Xmas

2012-12-24 Thread Andrea Giammarchi
just in case someone forgot the great job this group has done for the whole 2012 ... thank you from the community or, at least, from one of those devs out there using stuff decided in this group since ever! br ___ es-discuss mailing list es-discuss@mozil

Re: Dynamically changing of loader global

2012-12-24 Thread David Bruant
For that matter, you've implemented the "initial" solution in continuum [1] because you look at options.global when constructing the loader, but never look at it ever after. By the way, maybe you should Object-wrap it or throw if it isn't an object? The proposal doesn't say which should occur.

Re: Dynamically changing of loader global

2012-12-24 Thread David Bruant
Le 24/12/2012 23:37, Brandon Benvie a écrit : To clarify: are you asking if an arbitrary object is a valid global object when using a custom loader? If not, then I have a lot of code to rewrite. What I'm asking is: "is the global in the loader the initial or the dynamic value of the "global" o

Re: Dynamically changing of loader global

2012-12-24 Thread Brandon Benvie
I meant, if the answer to your question is "no". =/ On Mon, Dec 24, 2012 at 5:37 PM, Brandon Benvie wrote: > To clarify: are you asking if an arbitrary object is a valid global object > when using a custom loader? If not, then I have a lot of code to rewrite. > > > On Mon, Dec 24, 2012 at 5:34 P

Re: Dynamically changing of loader global

2012-12-24 Thread Brandon Benvie
To clarify: are you asking if an arbitrary object is a valid global object when using a custom loader? If not, then I have a lot of code to rewrite. On Mon, Dec 24, 2012 at 5:34 PM, David Bruant wrote: > Hi, > > I've reading the loader API [1] and I was wondering if it was possible to > dynamic

Dynamically changing of loader global

2012-12-24 Thread David Bruant
Hi, I've reading the loader API [1] and I was wondering if it was possible to dynamically change the global. I think it is by doing the following, but tell me if I'm wrong: const options = { global : { changeGlobal: function(g){ options.global = g;

'@std' and non-method versions of various methods?

2012-12-24 Thread Brandon Benvie
While seemingly out of date (though looks to have been updated recently), the modules_standard proposal is still listed as ostensibly part of harmony (ES6). For the most part it simply lists all the standard builtins from chapter 15 but there's a few new things in here. What caught my eye a while b

Re: Array.prototype.join with cycles

2012-12-24 Thread Brandon Benvie
I realized this is more appropriately filed as a bug (I think it's a spec bug anyway...) and have done so https://bugs.ecmascript.org/show_bug.cgi?id=1184. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.join with cycles

2012-12-24 Thread Brandon Benvie
I meant JSON.stringify explicitly specifies how to handle cycles. On Monday, December 24, 2012, Brandon Benvie wrote: > Given the following: > > var x = [1,2,3]; > x.push(x); > x+""; > > What should happen? The behavior demonstrated by V8, Spidermonkey, and > Chakra (haven't tested others) is to

Array.prototype.join with cycles

2012-12-24 Thread Brandon Benvie
Given the following: var x = [1,2,3]; x.push(x); x+""; What should happen? The behavior demonstrated by V8, Spidermonkey, and Chakra (haven't tested others) is to return the empty string for cycles, thus returning the result '1,2,3,'. However, unless I'm missing something, this behavior is unspec

Re: Changing [[Prototype]]

2012-12-24 Thread David Bruant
Le 24/12/2012 15:50, Brandon Benvie a écrit : That doesn't seem to be a problem. Host objects may be losing most/all of their magic but it's certainly reasonable that they have privileged access to capabilities. I think it makes sense to frame deleting __proto__ as simply removing access to a c

Re: Changing [[Prototype]]

2012-12-24 Thread Brandon Benvie
That doesn't seem to be a problem. Host objects may be losing most/all of their magic but it's certainly reasonable that they have privileged access to capabilities. I think it makes sense to frame deleting __proto__ as simply removing access to a capability from the user, but the capability still

Re: Changing [[Prototype]]

2012-12-24 Thread David Bruant
With the problem at hand and the solution currently being proposed (nodes changing of [[Prototype]] on adoptNode), it will remain possible to observe objects changing of [[Prototype]] after a "delete Object.prototype.__proto__". I don't know to what extends it's a good or a bad thing, but I tho

Re: Changing [[Prototype]]

2012-12-24 Thread David Bruant
Le 24/12/2012 10:48, Anne van Kesteren a écrit : I thought I'd give a heads up as over on www-...@w3.org we're discussing two cases where we likely need to change the prototype chain of objects: document.open() and methods that do the equivalent of document.adoptNode() (including that method itse

Changing [[Prototype]]

2012-12-24 Thread Anne van Kesteren
I thought I'd give a heads up as over on www-...@w3.org we're discussing two cases where we likely need to change the prototype chain of objects: document.open() and methods that do the equivalent of document.adoptNode() (including that method itself): http://lists.w3.org/Archives/Public/www-dom/2