Strict mode recap

There might be a slight misunderstanding here. In my example, the name
C.ns is constant, not a general expression; C needs to be a class, and
ns needs to be a static namespace definition inside that class (suitably
available).
In my (repentant) opinion the ns in _any_ ns::id expression must
reference a namespace binding that was not introduced into the scope by
"with" (and I'm happy to outlaw all such expressions in the body of a
"with", if that helps keep it simple).
I think you're trying to say something else too but I can't figure out
what it is, something about the ns in ns::id being a literal in a
stronger sense than what I just outlined?
--lars
________________________________
From: Brendan Eich [mailto:brendan at mozilla.org]
Sent: 11. april 2008 13:44
To: Lars Hansen; Jon Zeppieri
Cc: es4-discuss at mozilla.org es4-discuss; liorean
Subject: Re: Strict mode recap
On Apr 11, 2008, at 10:22 AM, Lars Hansen wrote:
(It _is_ an indication that the syntax used in
the object initializers is not fully general, though,
since it only
allows simple identifiers in the namespace position.
Sigh.)
I've argued that JS's literal property identifiers in object
initialisers, instead of mandatory quoted strings for literal names and
evaluated expressions for runtime naming, is a virtue, pace Python. It
certainly reduces the quote burden compared to JSON or Python. It allows
readers and compilers to make static judgments about what names are
bound in the object created for the initialiser. Anyway, it's an old
decision, hard to change now.
I'm mailing mainly to ask whether this restriction is something
considered harmful in ES4 with namespaces, or for any other reason. I
think Jon and I have agreed in the past on namespaces being constant,
but argument has evolved since then.
My reason for agreeing with Jon then was that readers, never
mind compilers, otherwise can have a hard time figuring out the meaning
of names. This is always hard with globals, less so with outer names in
closures, and no picnic with property initialisers if you add computed
namespaces to them.
I don't have a stronger reason than favoring comprehension and
easing implementation, though. The second is less important than the
first, but we consider efficiency too.
/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20080411/efada9e1/attachment-0002.html