Brendan Eich wrote:
> On Mar 8, 2008, at 1:16 PM, Yuh-Ruey Chen wrote:
> > But doesn't DontEnum still have to be there for ES3 objects? How else
> > would you prevent the enumeration of ES3 builtin methods, e.g.
> > Object.prototype.toString()? Or is there some more open namespace
> > magic
> > that I'm unware of?
>
> ES3 code can't detect namespaces, so arguably shouldn't care if we
> were to implement DontEnum using an open namespace. But this could be
> a problem for mixed ES3 and ES4 scenarios where the ES4 code does
> introspect via Name objects and is surprised to find "ES3" objects
> with qualified property names.
>
I'm talking about how the enumerability (or lack thereof) of
Object.prototype.* are determined. Or are prototype methods also not
enumerable by default like fixtures?
Let me get this straight. The rules of enumerability are:
1) If a property is a fixture, it's not enumerable. BTW, what exactly is
a fixture? Does this included ES3-style prototype methods? And would it
be possible to init a fixture to be enumerable?
2) If a property is not in the public namespace, it's not enumerable.
3) Otherwise, it is enumerable.
4) No hidden DontEnum attribute.
Are we trying to simplify this to the last three rules using some
namespace voodoo to handle the fixture rule? I'm confused.
> > Well, I think the only overlap is that public-in-class-context methods
> > (or any method really) default to be non-public in terms of
> > enumerability
>
> Is that the right design?
>
> dynamic class C {
> public var fixture;
> function C() { this.expando = 42; }
> }
> for (var i in new C)
> intrinsic::print(i);
>
> wouldn't you expect to see "expando" printed? Is it printed because
> the default namespace for expando is the public-default one? I
> believe it is not, in the current proposal and the RI. Rather, each
> class or package gets a nonce-named public namespace, different from
> every other such per-class or per-package public. IIRC package trumps
> class -- classes within a package share the package's nonce-named
> public namespace (Jeff, Lars, please correct me if I'm wrong).
>
I meant non-expando vars and methods defined within the class, whatever
the terminology is used (I see 'fixture' thrown around everywhere), are
not enumerable. So yes, expando should be printed. And the RI does print
it, so I'm not sure what you're talking about. Are you saying that each
property is defined in a "class-specific public" namespace, and
therefore does not get enumerated? I would say that expando properties
should be defined in the "global public" namespace, so that they would
be enumerated.
-Yuh-Ruey Chen
_______________________________________________
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
