On Mar 9, 2008, at 3:01 PM, Yuh-Ruey Chen wrote: > Brendan Eich wrote: >> 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?
My reply was not meant to be an answer, but a question: should we drop this dontenum-namespace idea because it will break ES3+ES4 mixtures where the ES4 code reflects on a property's namespace qualifier by using a Name object? > Let me get this straight. The rules of enumerability are: > 1) If a property is a fixture, it's not enumerable. I never said any such thing. My hope was to avoid special cases and use only a predefined, opened-by-definition namespace. > BTW, what exactly is a fixture? That's a good question, and it seems the answer is not in the wiki. Trying the trac: http://bugs.ecmascript.org/ticket/233 which references the overview document. In ES3 terms, a fixture is a property with the DontDelete attribute set. But there's more to it than that, for reasons expanded on in #233 to do with namespace lookup and early binding. And there is another case that Lars pointed out recently to do with dynamic classes, but I'll avoid trying to summarize it except to say that a fixture is a fixed property that can't be deleted or shadowed. > Does this included ES3-style prototype methods? And would it > be possible to init a fixture to be enumerable? In the sketch I mailed, you didn't see any mention of fixtures -- IIRC you asked about them in reply. Just to explain what my proposal was aiming to do: It seems to me that if we have to add a magic bit back into the skinny is-it-enumerable decision tree, we may as well keep DontEnum. > 2) If a property is not in the public namespace, it's not enumerable. Right, I said that ;-). > 3) Otherwise, it is enumerable. > 4) No hidden DontEnum attribute. 4 is more of an aside than a step, but yeah, that's it :-). > Are we trying to simplify this to the last three rules using some > namespace voodoo to handle the fixture rule? I'm confused. My proposal had no mention of fixture "voodoo" -- you cast that spell ;-). Notice that most DontEnum (almost all) properties defined by ES3 are not fixtures because they are not DontDelete. IIRC only a few such as standard prototype's constructor properties are DontDelete. >> 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 (Not in my proposal) > ), are > not enumerable. So yes, expando should be printed. From your numbered steps above, step 3 must have been reached -- so expando is in the public-public (null qualifier in Name object reflection) namespace. Not in the class-C-public namespace. My question is whether that is the right design choice. > And the RI does print > it, so I'm not sure what you're talking about. The RI is (a) not normative (nothing apart from ES3+fixes is yet), (b) based on a DontEnum attribute model, not on my proposal. Not sure why you thought I was talking about it. I was making a new proposal. > 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. Ok, I like that. I'm not arguing a side, just showing the choice. There may be other cases, though, where a class-public property name might want to be enumerable. In such a case the step 2 you wrote would need to elaborate its "public" test. But again, my proposal was about enumerability, independent of fixture-ness. /be _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
