- From: Domenic Denicola <notifications@github.com>
- Date: Fri, 13 May 2016 10:10:09 -0700
- To: heycam/webidl <webidl@noreply.github.com>
- Cc:
- Message-ID: <heycam/webidl/pull/121/r63217619@github.com>
> + > + > + <div class='example'> > + <p> > + The following <a class='dfnref' href='#dfn-idl-fragment'>IDL fragment</a> defines an > + <a class='dfnref' href='#dfn-namespace'>namespace</a>. > + </p> > + <x:codeblock language='idl'>namespace VectorUtils { > + double dotProduct(Vector x, Vector y); > + Vector crossProduct(Vector x, Vector y); > +};</x:codeblock> > + > + <p> > + An ECMAScript implementation would then expose a global property named > + <code>VectorUtils</code> which was a simple object (with prototype > + <a>%ObjectPrototype%</a>) with non-enumerable data properties for each declared I was torn on this. Safari indicated a desire to match ES's namespaces (Math, Reflect, JSON) which are not. And, `Object.keys(console)` currently returns `[]` because of the prototype separation; this preserves that. To me, it seems more likely people are depending on `Object.keys(console)` being empty (so that e.g. `Object.keys(console)` returns any methods they themselves added), than that they are depending on `Object.getOwnPropertyDescriptor(console, "log").enumerable` being true. I guess maybe they are using `for`-`in` though, which does change. I should probably flip this. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/heycam/webidl/pull/121/files/70ba6d9c213e2b05cf0d8b3ebd14ce9a4583f4c6#r63217619
Received on Friday, 13 May 2016 17:10:37 UTC