On Mar 10, 2008, at 6:43 PM, Yuh-Ruey Chen wrote: > Ok, that cleared things up a bit. I didn't realize you were making a > proposal and asking questions based off it :)
This is my fault for being unclear. I wrote: Here's something I wrote a while ago (minor edits to update for context) that attempts to subsume enumerability under namespacing: and made a proposal. The "attempts to subsume" bit was not as clear as it could have been that I was making a novel proposal. Sorry about that. > Can you elaborate on cases where "ES4 code does introspect via Name > objects and is surprised to find "ES3" objects with qualified property > names."? I can't think of any. I can't think of one right now, but the thought comes from the http://wiki.ecmascript.org/doku.php?id=proposals:meta_objects proposal, where you can reflect on names of types, at least. True, you can't iterate over all properties of an object, e.g., the expando example. But type names can be namespaced, and the Name object is used to reflect these. If we end up making all namespaced properties non-enumerable, then we may want a property iterator that returns the names of all properties in a given object. Even if this is not in the standard, it's likely to be an extension. Or it could be added in the future. The question of whether ES3+4 mixtures might not want enumerable ES3 properties to appear to be in a predefined-in-ES4 namespace seems to me worth considering, at the limit as a future-proofing step. >> 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. >> > > Thanks, that's a good summary, though some of the commentary in the > ticket was confusing (like lth's example - was x.toString decided > to be > ambiguous?). No, the ticket is open and it needs more work. I wonder, though, whether Lars's example does not show how 'use namespace intrinsic' in that lexical scope (block) simply makes that open namespace take precedence. Since there is no explicitly opened public namespace in that scope, x.toString there resolves to x.intrinsic::toString. The RI is buggy, it does not make const property initialisers DontDelete: >> var x = { const toString: 37 } { use namespace intrinsic x.toString } >> >> >> >> [function Function] >> x.toString 37 >> x.toString = 42 42 >> x.toString 37 >> delete x.toString true >> x.toString [function Function] I filed http://bugs.ecmascript.org/ticket/372 on this RI bug. We should work on this ticket more in the near term, I think. /be _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
