Re: Alternative proposal to privateName.public

Le 22/12/2011 13:20, Tom Van Cutsem a écrit : > (...) > > Having also just read about the different use cases of "private" names > versus just "unique" names, it would make a lot of sense to me if we > would separate these two (either via a flag or via different > constructors): > > - private names

Confused by Firefox: own property with a descriptor not listed by getOwnPropertyNames()

I’m a bit confused by the following interaction on Firefox: > Object.getOwnPropertyNames(new Error()) [] > Object.getOwnPropertyDescriptor(new Error(), "stack") {…} That does not make sense to me. Shouldn’t the property be either accessible in both cases or in neither case? --

Re: Alternative proposal to privateName.public

2011/12/22 Tom Van Cutsem : > At first, I shared Andreas's concern about introducing a flag in feature X > that only seems to affect a superficially unrelated feature Y. > > However, having skimmed the private names page, I stumbled upon a section > that seems to want to introduce precisely such a

Re: Alternative proposal to privateName.public

Le 26/12/2011 15:56, Erik Corry a écrit : > 2011/12/22 Tom Van Cutsem : >> At first, I shared Andreas's concern about introducing a flag in feature X >> that only seems to affect a superficially unrelated feature Y. >> >> However, having skimmed the private names page, I stumbled upon a section >>

Re: Alternative proposal to privateName.public

2011/12/26 David Bruant : > Le 26/12/2011 15:56, Erik Corry a écrit : >> 2011/12/22 Tom Van Cutsem : >>> At first, I shared Andreas's concern about introducing a flag in feature X >>> that only seems to affect a superficially unrelated feature Y. >>> >>> However, having skimmed the private names pa

Re: Alternative proposal to privateName.public

Le 26/12/2011 16:37, Erik Corry a écrit : > 2011/12/26 David Bruant : >> Le 26/12/2011 15:56, Erik Corry a écrit : >>> I don't see how you need anything new in the language to support unique >>> names. >>> >>> >>> var newUniqueName = (function() { >>> var counter = 0; >>> return function () {

Re: Alternative proposal to privateName.public

2011/12/26 David Bruant : > Le 26/12/2011 16:37, Erik Corry a écrit : >> 2011/12/26 David Bruant : >>> Le 26/12/2011 15:56, Erik Corry a écrit : I don't see how you need anything new in the language to support unique names. var newUniqueName = (function() {   var coun

Re: Alternative proposal to privateName.public

Le 26/12/2011 17:27, Erik Corry a écrit : > 2011/12/26 David Bruant : >> Le 26/12/2011 16:37, Erik Corry a écrit : >>> 2011/12/26 David Bruant : Le 26/12/2011 15:56, Erik Corry a écrit : > I don't see how you need anything new in the language to support unique > names. > > >>>

Re: Alternative proposal to privateName.public

Le 26/12/2011 14:40, David Bruant a écrit : > (...) > I've given more thought to this idea. > For a second, let's imagine we have 2 independent flags: "visible" (or > "reflectable") and "trapped". It would make 4 cases: > 1) visible & trapped > 2) invisible & trapped > 3) visible & untrapped > 4) i

Re: Alternative proposal to privateName.public

On Mon, Dec 26, 2011 at 7:54 AM, David Bruant wrote: > > On a side note, I have seen a talk where someone mentionned that the > "use the same JavaScript in server and client" was partially bullshit, > because Node has support for some ES5 features that legacy web browsers > can't even emu[l]ate.

Re: Alternative proposal to privateName.public

Oh, and we prevent access to all property names that end in "__" (double underbar), which again is probably not what that speaker had in mind. On Mon, Dec 26, 2011 at 10:40 AM, Mark S. Miller wrote: > On Mon, Dec 26, 2011 at 7:54 AM, David Bruant wrote: > >> >> On a side note, I have seen a tal

Re: Alternative proposal to privateName.public

On Mon, Dec 26, 2011 at 8:27 AM, Erik Corry wrote: > > On a side note, I have seen a talk where someone mentionned that the > > "use the same JavaScript in server and client" was partially bullshit, > > because Node has support for some ES5 features that legacy web browsers > > can't even emuate.

Re: Alternative proposal to privateName.public

Le 26/12/2011 19:40, Mark S. Miller a écrit : > On Mon, Dec 26, 2011 at 7:54 AM, David Bruant > wrote: > > > On a side note, I have seen a talk where someone mentionned that the > "use the same JavaScript in server and client" was partially bullshit, > becaus

Re: Alternative proposal to privateName.public

> For another the modules infrastructure that you have on > node is (for good reasons, I suspect) completely different to the > infrastructure available on the client, which makes a difference to > the way you structure your program. I’ve heard that claim many times, but I have yet to see compell

Re: Alternative proposal to privateName.public

On Mon, Dec 26, 2011 at 11:08 AM, David Bruant wrote: > Le 26/12/2011 19:40, Mark S. Miller a écrit : > [...] > A pointer would be appreciated, thanks. Caja has a rather complete > emulation of ES5 that runs in legacy browsers going back to IE6. [...] > > You can try out our emulation online a

ES5 Module Systems (was: Alternative proposal to privateName.public)

[Note change of Subject:] On Mon, Dec 26, 2011 at 12:15 PM, Axel Rauschmayer wrote: > For another the modules infrastructure that you have on >> node is (for good reasons, I suspect) completely different to the >> infrastructure available on the client, which makes a difference to >> the way yo

Re: ES5 Module Systems (was: Alternative proposal to privateName.public)

> > However, I am confused by the "module.exports = ..." part of your > boilerplate. The main CommonJS wiki seems down at the moment, but looking > at > on the mirror site, I could not find any support for this idiom. The > clos

Re: ES5 Module Systems (was: Alternative proposal to privateName.public)

> Hi Axel, a nice demonstration of the simplicity of the core of AMD is the > simplicity with which it can be implemented using a promise library. Exactly; nice demo. Doing something comparably asynchronous with Node.js modules (without a compilation step) is much more hacky: http://www.2ality.c

Re: ES5 Module Systems (was: Alternative proposal to privateName.public)

> IMHO, the best option is still boilerplate (to conditionally turn an AMD into > a Node.js module): > ({ define: typeof define === "function" > ? define > : function(A,F) { module.exports = F.apply(null, A.map(require)) } }). > define([ "./module1", "./module2" ], >

Re: Alternative proposal to privateName.public

Le 26/12/2011 22:28, Mark S. Miller a écrit : > On Mon, Dec 26, 2011 at 11:08 AM, David Bruant > wrote: > > Le 26/12/2011 19:40, Mark S. Miller a écrit : > > [...] > >> A pointer would be appreciated, thanks. Caja has a rather >> complete emulation of ES5 th

Why we need to clean up __proto__

Or, "Even Crock's Code Doesn't Overcome All The Bad Parts." In this message, I explain why I believe we need to clean up __proto__. I'll start a separate thread on how to clean it up -- which is just my documenting a suggestion from Dave Herman. >From < http://eleventyone.done.hu/OReilly.JavaSc

Re: ES5 Module Systems (was: Alternative proposal to privateName.public)

On Mon, Dec 26, 2011 at 1:46 PM, Mark S. Miller wrote: > On Mon, Dec 26, 2011 at 12:15 PM, Axel Rauschmayer wrote: >> The adapters are all a bit cumbersome to use. IMHO, the best option is >> still boilerplate (to conditionally turn an AMD into a Node.js module): >> >> ({ define: typeof defin