On Mar 8, 2008, at 1:16 PM, Yuh-Ruey Chen wrote:
> Brendan Eich wrote:
>>> - Users may think this dontenum namespace is magical and yet another
>>> thing to keep in mind, when it really just relies on the namespace
>>> trick
>>> you mentioned. With the introduction of classes and namespaces, the
>>> rules of enumerability are already more complex, so this adds to the
>>> cognitive load slightly.
>>
>> Slightly, but it takes away the magic DontEnum attribute, formerly
>> hogged by the specification and magic predefined objects.
>
> 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.
>>> BTW, if setPropertyIsEnumerable() is added,
>>> would it be possible to make fixtures enumerable? Enumerability is
>>> orthogonal to static analysis (which fixtures are meant to help
>>> with),
>>> so I don't see why not.
>>
>> This gets to the heart of the public vs. public-in-context-of-class-
>> or-package issue. We need to sort this out to find out exactly how
>> orthogonal enumerability is, as well as decide how flexible it should
>> be.
>>
>
> 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).
> While we're on the topic of namespaces, I read in the ES4 overview:
> "In
> addition, the names internal, public, protected, and private denote
> namespace values, but the values depend on the context of the use." As
> the wiki doesn't talk about this, and the online spec is
> inaccessible/outdated, can you elaborate on this? I wonder if
> 'private'
> could be used somehow for enumerability.
This is the entire issue. See above and let me know if that's unclear.
/be
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
