> I'm very happy that Harmony itself will be a successor only to ES5/strict. > That said, I do expect such lexical declarations to be de facto for > non-strict code, so we should document as much agreement on their semantics > as we can get. Perhaps at > <http://wiki.ecmascript.org/doku.php?id=conventions:recommendations_for_implementors>?
If it is going to be a de facto standard then it should be included in Harmony. These days, Microsoft's primary interest in contributing to web standards development is to ensure interoperability of user written code among browsers. We would much prefer that anything that is expected to be universally implemented in an interoperable manner is included in an official standard. I don't think we have any real disagreement here other than the possible perception that Harmony can only talk about strict mode functionality. Allen From: Mark S. Miller [mailto:[email protected]] Sent: Wednesday, July 07, 2010 10:56 PM To: Allen Wirfs-Brock Cc: [email protected]; es-discuss Subject: Re: global function declarations and predefined global properties [+es-discuss] On Wed, Jul 7, 2010 at 6:28 PM, Allen Wirfs-Brock <[email protected]<mailto:[email protected]>> wrote: Yes, except that the ES5 spec. only defines what it defines...any non-standard extenders are on their own when trying to leverage ES5 spec. language so define their semantics. It may or may not fit some new use. Also, if you think that such non-strict lexical declaration are going to be a de facto standard language feature than you should probably be campaigning to add them to the Harmony standard. I'm very happy that Harmony itself will be a successor only to ES5/strict. That said, I do expect such lexical declarations to be de facto for non-strict code, so we should document as much agreement on their semantics as we can get. Perhaps at <http://wiki.ecmascript.org/doku.php?id=conventions:recommendations_for_implementors>? If you wanted to have lexically scoped declarations within with blocks, why assume that they would add properties to the with object. Why shouldn't such declaration be defined in a declarative scope that is nested within the with object scope? The conflict I was worried about is that both "with" and global scope use object environment records, effectively treating the top level as if within a "with (global) {...}" block. However, now that you raise it, we can retroactively rationalize "with" as creating an object environment record and nested within it a block-level declarative environment record <http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_bindings#common_semantics>. By contrast, we explain global scope as just an object environment record. This justifies adding block level global declarations to the global object but not adding block level declarations to the with object. Great suggestion, thanks! From: Mark S. Miller [mailto:[email protected]<mailto:[email protected]>] Sent: Wednesday, July 07, 2010 5:58 PM To: Allen Wirfs-Brock Cc: [email protected]<mailto:[email protected]> Subject: Re: global function declarations and predefined global properties AFAICT, the issue would also arise for "with" statements if the body of a "with" statement could contain a definition which is not hoisted around the "with". Although ES5 does not provide any such non-hoisted definitions, neither does it prohibit them. Three such non-hoisted definitions are expected in ES-next: "let", "const", and nested function definitions. Since several browsers are expected to support these for ES5 non-strict code[*], this issue will arise for "with" in these ES5 implementations. [*] <http://wiki.ecmascript.org/doku.php?id=conventions:recommendations_for_implementors> -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
