- 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