ES3.1: Draft 1

[Pratap Lakshman (VJ#SDK)]

Some parts of this message have been removed. Learn more about Nabble's security policy.

I have uploaded to the wiki (link, see bottom of the page) a first draft of the specification for ES3.1. This is in the form of in-place edits and markups to the ES3 specification. As you will notice when reading through, there are still some open issues, and details on a few features to be filled in. This spec shall be updated as we make progress on these.

 

pratap

 

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Maciej Stachowiak]

On May 28, 2008, at 10:38 PM, Pratap Lakshman (VJ#SDK) wrote:

I have uploaded to the wiki (link, see bottom of the page) a first draft of the specification for ES3.1. This is in the form of in-place edits and markups to the ES3 specification. As you will notice when reading through, there are still some open issues, and details on a few features to be filled in. This spec shall be updated as we make progress on these.

 

I have only skimmed the beginning of the document. The following change seems like a technical error:

"All constructors are objects, but not all objects are constructors." 

  -->

"All constructors are functions, but not all functions are usefully treated as constructors."

ECMAScript constructors need not be functions; an object may implement the [[Construct]] internal property without also implementing the [[Call]] internal property, thus it would be a constructor but not a function. I assume it was not the intent to deliberately remove this possibility.

Also, the addition of "usefully treated as" does not make sense. An object that does not implement the [[Construct]] internal property is not a constructor at all, rather than merely "not usefully treated as" a constructor.

The definition from the original spec that actually seems wrong is in 4.3.4, "A constructor is a Function object that creates and initialises objects."

With a lot of the changes, I could not tell if the intent was to change language semantics or to make a clarifying editorial change.

Regards,

Maciej

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Pratap Lakshman (VJ#SDK)]

Some parts of this message have been removed. Learn more about Nabble's security policy.

I have uploaded to the wiki (link, see under "Draft Specification") the current draft of the specification for ES3.1. This is in the form of in-place edits and markups to the ES3 specification. Revision history is at the end of the document.

 

pratap

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Lars Hansen-3]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Attaching comments.

 

In general this looks pretty clean.  (Some obvious missing parts excepted.)  Of the things that do not look clean I want to single out three worries specifically: That your strict mode is overreaching, that too much (any!) emphasis is placed on catering to a non-existent "secure subset" language, and that strict compatibility has not been maintained with JS1.6/1.7/1.8 in the methods incorporated from those specifications.  See the comments for details.  Also, there are numerous occasions where the proposed language is incompatible with Proposed ES4, so we have work to do to reconcile them.

 

--lars

---

From: es4-discuss-bounces@... [mailto:es4-discuss-bounces@...] On Behalf Of Pratap Lakshman (VJ#SDK)
Sent: 12. juni 2008 02:02
To: es3.x-discuss@...
Cc: es4-discuss@...
Subject: ES3.1 Draft: 11 June 2008 version available

I have uploaded to the wiki (link, see under "Draft Specification") the current draft of the specification for ES3.1. This is in the form of in-place edits and markups to the ES3 specification. Revision history is at the end of the document.

 

pratap

p1.  "... some aspects of the language were defined to operate by
non-strict rules that are quite error prone. For backwards
compatibility, this "non - strict mode" remains the default. But a
scipt can now explicitly declare that it is in "strict mode", which
should make programming more robust for both professionals and
non-professionals."

Editorializing of this sort ("..are quite error prone.") is
inappropriate in a language standard.  It would be better simply to
note that the new strict mode catches more errors and that this
benefits large programs in particular.



p2.  The inserted reference to the Scheme report appears to be
gratuitous, as Scheme is not mentioned elsewhere in this document
(notably not in the preceding paragraph that mentions Java and Self).
Also, if you're going to mention Scheme then it would be better to
reference the last report (R6RS) or the IEEE standard (based on R4RS).


p2.  4.2#2 The deletion of "is an" to be replaced by "a" makes the
sentence grammatically incorrect.


p2.  4.2#2 (and throughout the document) Merriam-Webster's Collegiate
insists on "writable" and not "writeable".  But of course that book
documents US English, and as a non-native speaker of English I'm not
on firm ground here, so I would encourage the input of others.


p2.  4.2#4 The change in wording brings about a change in meaning that
is not obviously desirable, since the original wording allows more
implementation techniques than the new wording.


p3.  4.2.1#1 Inconsistent typography.  If you look forward to eg 13.2,
the typesetting for the prototype property is bold monospace; here you
have non-bold monospace with quotation marks.  Nobody disputes (I
think) that the ES3 spec could be cleaned up in this regard, but I
feel that the change here is just making matters worse.  Whatever you
do, using both monospace and quotes is inappropriate IMO.


p3.  4.2.1#2 This change does not clarify -- the new language is no
less confusing than the old -- and should be reverted.  (Furthermore,
the reference is not implicit, but the old spec got that wrong too.)


p4.  4.2.2 Again, editorializing ("error-prone behaviours") is
inappropriate for a language specification.


p5.  4.3.15.  No, you can't get rid of wrappers in strict mode (it
would violate the ES3.1 - ES4 subset relationship, for one thing).


p5.  4.3.24.  Wording: note that all the preceding paragraphs use
"instance of the built-in X object" not "X constructor".  Suggest you
follow that here.  Semantics: the notion of "primitive function"
appears nowhere else in the document that I can find and should
probably not be introduced here.  Conceivably it could be used to
explain the behavior of Function.prototype.toString on host and native
functions, but as those concepts are already present in ES3 they would
be the better choice.


p8.  5.1.4.  Disabling semicolon insertion in strict mode breaks the
ES3.1 - ES4 subset relationship.


p10.  5.2.  Though this algorithm notation is an improvement over what
ES3 uses, I question whether it's reasonable to introduce it without
changing all the algorithm descriptions, something I expect you will
not do.  IMO you should remove this, and new algorithms should be
described using the same notation as algorithms carried over from ES3.


p13.  7.2, 7.3.  LS is U+2028 and PS is U+2029, not the values shown
here.  Also, making LS and PS change status from line separator to
whitespace appears to be a gratuitous change.  Also, ZWSP is a format
control character in the unicode database, not a whitespace character,
and I'd like to know why this should be singled out if not U+FEFF
(zero width no-break space) should not be incorporated too;
significantly, the latter doubles as the byte order mark (BOM) and ES4
will treat it as a whitespace character between tokens (and as itself
inside string and regular exprssion tokens).

I propose that you not change the status of LS and PS and that you
incorporate U+FEFF in the set of whitespace characters.


p14.  7.5.  The inclusion of IdentifierName here appears to have no
effect since Identifier = IdentifierName except ReservedWord.  Suggest
you remove this.


p15 7.5.2.  Making 'eval' a reserved word breaks the ES3.1 - ES4
subset relationship and breaks the web.


p15 7.5.2.  Making 'const' a reserved word appears gratuitous since
ES3.1 does not use it.  Please undo this change.


p15 7.6.  Removing the comment about allowing identifier characters
from later versions of Unicode breaks the ES3.1 - ES4 subset
relationship.


p22 7.8.  Unacceptable change: The requirement to signal regular
expression syntax errors at scanning time breaks existing programs.
(The justification ("since the arguments are the same every tine[sic],
..." appears to have no bearing on that and should be removed in any
case.)


p22 7.9.  Requiring semicolons in strict mode breaks the ES3.1 - ES4
subset relationship.


p26 8.6.1.  (And throughout the spec) The meaning of "dynamic" in ES4
is something else (it means a non-fixture property).  It would
probably reduce confusion if the property name Deletable were used
here, as I though we had agreed previously.


p27 8.6.1.  ES4 specifies that the missing sibling of the
getter/setter pair is generated by the system, so [[Getter]] and
[[Setter]] would never be undefined, they would always be functions.
We've done this because we feel it simplifies the language
specification in other places (fewer cases).


p27 8.6.2.  Not sure that introducing a notion of "inheritance" here
is useful, since properties are really not copied down to objects;
dynamic properties in prototype objects can become visible and
disappear again without any change to the object that points to the
prototype.  Suggest you undo this language.


p27 8.6.2.  Again, the attempt to emasculate host objects is likely to
introduce incompatibilities.  Suggest you leave this language alone.


p28 8.6.2.  Suggest [[IsDynamic]] rather than [[Dynamic]] in order to
avoid confusion with [[Dynamic]] used elsewhere and to conform to the
pattern used elsewhere, in that predicates have a verb in the name.

p28 8.6.2.  Remove [[Identity]], it makes no difference.


p29 8.6.2.1.2.  The first two steps are duplicated.  Also,
disginguishing a Number property here is probably wrong, as for other
objects a["10"] and a[10] mean the same thing always.  Also, this
algorithm has more spaghetti than it needs (steps 6-8 should be
inlined into 3).  Also, I'm pretty sure this implementation does not
correspond to what's in most browsers, because they usually only query
the string for property names within the string's length, and go to
the underlying object for other names.


p29  8.6.2.1.3.  [[SetOwnProperty]] is not actually used anywhere.

p30 8.6.2.2.  If I read this correctly you have changed the semantics
of properties by removing the use of [[CanPut]].  (ES4 Draft 1 has the
same bug.)  Also, [[Put]] returns a value but the spec in the
preceding table does not specify that, and the value is not used by
any caller of [[Put]] anywhere in the document.


p30 8.6.2.4.  This implementation of [[HasProperty]] is not equivalent
to the one in ES3 -- it may end up invoking String.prototype.charAt.
What you want to do in that case is to see if the index is within the
bounds of the string, and if so return true, and if not, query the
property on the object in the normal fashion.


p30 8.6.2.5.  This has the same problem as [[HasProperty]], it may end
up invoking charAt.  Also, the "else" in clauses 5 and 6 are redundant
(ditto in some of the preceding algorithms).


p31 8.7.  I think you should not delete the sentence "No built-in
ECMAScript function defined by this specification returns a reference
and there is no provision for a user-defined function to return a
reference."  ES4 will not use references in the specification; this
will not prevent implementations from providing them, and there will
be some syntactic cruft in ES4 to allow ES3 programs written for IE to
continue to be syntactically valid.


p40 10.1.2.  Second bullet, the language here is clumsy.  AFAIK there
is no way to disable strictness, so the use of "switched" is not right
either.


p41 10.1.6.  "mentions 'arguments' freely" needs to be explained in
more detail.


p41 10.1.8.  Creating "callee" only for non-strict code breaks the
ES3.1 - ES4 subset relationship.  Also, I have said it before and it
looks like I will have to continue to say it, the arguments object
*cannot* be an Array.  The prototype object of the arguments object is
the original Array.prototype value, but that's all.  Please see
extensive discussions in the wiki on this.  (Making it an Array in
ES3.1 will break the ES3.1 - ES4 subset relationship.)


p42 10.1.1.  We all hate this sharing, but you're stuck with it.
(Mind the subset relationship...)


p42 10.2.2.  I think the current conclusion for ES4 is that variable
instantiation in the eval caller is OK as long as the caller is
non-strict, whether the eval code itself is strict or not does not
make a difference.  I suspect this is the right tradeoff (you get
error checking inside the eval code).  Also, you need to spec what
happens here.  In ES4, the thought is that you get a SyntaxError from
eval if it tries to introduce top-level names and the context does not
allow it.


p47 11.2.3.  The comment is irrelevant, because MSIE can be free to
extend semantics (and syntax for that matter) for its own purposes.


p64 12.2.  Careful here, this should be [[Dynamic]]=false.  For the
'var' statement, these properties are tagged DontDelete in the global
object. You're not right in asserting that FF allows them to be
deleted, as this script (which prints '10' twice in FF) shows:

  var x = 10;
  document.writeln(x);
  delete x;
  document.writeln(window.x);

Dynamically created globals (created by assignments only) are
different, they should be deletable.


p65 12.5.  This comment is curious, apart from in catch handlers and
in named function expressions there are no block-local binding, and
even the latter case should probably be interpreted differently.


p69 12.10.  Disallowing the with statement in strict mode breaks the
ES3.1 - ES4 subset relationship (we've found no compelling reason to
ban it).


p74 13.  The comment asks, is it observable that the function is
stored in an enumerable property?  The answer is yes.  (The secret is
in 11.2.3 and in lines 1 and 2 of the present algorithm.)  This should
print "n":

  (function n(x) {
      if (x) return this;
      for (var v in n(true))
          print(v);
  })(false)



p76 14.  I know you like strict mode, but presumably this pragma ought
to be optional, not mandatory.


p77 15#5.  Looks like a gratuitous change.  Motivation?


p78 15.1.1.  Incompatible change, and incompatible with ES4 (which
makes these properties not only DontDelete and DontEnum, but ReadOnly
as well).  The ReadOnly-ness in ES4 is unconditional (and so also
incompatible with ES3, strictly speaking); maybe going in that
direction will be better for ES3.1.


p78 15.1.2.1.  ES4 strict mode will not require an EvalError to be
thrown, nor should ES3.1.  


p85-87 15.2.3.2 - 15.2.3.15: these conflict in various ways with ES4
and will likely not be adopted by that language in the form they are
exhibited here.  Specificially

  - sealing, freezing, and prototype reading are unlikely to be in ES4
  - beget is (though the description is missing I understand it creates
    an object with a specific prototype value and a few specific
    objects) handled by syntax and is not needed in ES4
  - many of the other algorithms are probably best expressed in terms
    of iterators and enumerators in ES4
  - as earlier discussion has shown, we object (on aesthetic and
    efficiency grounds) to some of these APIS.

No doubt we'll have much fun discussing this during future meetings.


p90 15.3.4.5.  The description of 'bind' needs to be improved
substantially, it should be easy enough to express it using the normal
pseudocode or even ES3.


p90 15.3.5.2.  Incompatible with ES4, breaks the subset relationship.


p90 15.4.3.2.  Probably to spell out that this is required to work
across global objects and to note that 'instanceof' does not.


p100 15.4.4.14.  I am reasonably confident that this algorithm is not
consistent with the one published as part of the JS1.6 spec:

http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Objects:Array:indexOf

In particular, note how the latter algorithm only performs the ===
comparison if the index is present in the array, whereas steps 12-14
simply call [[Get]] and use the result.  I am also not confident that
the bounds computations are equivalent.

(As it happens I'm not sure that the code on the mozilla site is 100%
what we want either, in particular, unlike array methods in ES3 it
does not appear to bound the length above at 2^32-1, for better or
worse).

Anyway, anything that isn't essentially 100% compatible with the
published 1.6 spec will also not be compatible with what's in ES4.

I have not checked the algorithms in the following sections.


p131 15.9.1.15.  This is not acceptable: "Illegal values
(out-of-bounds as well as syntax errors) in the format string shall
cause Date.parse to return NaN".  Date.parse needs to be required to
give preference to ISO format strings and strings that have the format
returned by Date.toString.  Everything else is between Date.parse and
its maker.


p132 15.9.4.2.  Same comment.  The language here does not make sense.
First, it breaks the web -- Date.parse must cope with the many formats
out there right now.  Second, it is internally contradictory: it says
that Date.parse shall return NaN if the ISO format is not met; then it
says something incoherent about implementation-defined heuristics.


p139 15.9.5.42.  Propose you remove the NOTE here, which contradicts
the normative text.  The string is supposed to be "human-readable"
which indicates something richer than ISO format.


p139  15.9.5.44.  Date.prototype.toJSON is not going to be in ES4, and
IMO it does not belong here.


p155  15.10.7.5.  I don't understand this comment.


p158 15.12.  We have not considered JSON for ES4 and will probably
need some time to determine whether this API is suitable (presumably
after this section has been completed; it appears to be in an
intermediate state).



_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[André Rømcke]

Hi, and thanks for any work on making ES3 better while we wait for ES4!


One thing I miss form the targeted additions part of the spec is:
function.bindEvent aka function.bindEventListener

The difference from function.bind is that binded arguments are appended
after instead of before the arguments when called.

Example code for function.bind and function.bindEvent (where arguments is
a true array):


function.bind = function()
{
    // Binds arguments to a function, so when you call the returned
wrapper function,
    // arguments are intact and arguments passed to the wrapper function
is appended.
    // first argument is 'this' and the rest is arguments
    var args = arguments, __fn = this, __object = args.shift();
    return function(){ return __fn.apply(__object, args.concat(arguments))};
};

function.bindEvent = function()
{
    // Same as bind, but prepends the arguments to the wrapper function
    var args = arguments, __fn = this, __object = args.shift();
    return function(){ return __fn.apply(__object, arguments.concat(args))};
};



http://wiki.ecmascript.org/doku.php?id=es3.1:targeted_additions_to_array_string_object_date

On Thu, June 12, 2008 2:01 am, Pratap Lakshman (VJ#SDK) wrote:
> I have uploaded to the wiki
> (link<http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft>,
> see under "Draft Specification") the current draft of the specification
> for ES3.1. This is in the form of in-place edits and markups to the ES3
> specification. Revision history is at the end of the document.
>
> pratap
>


--
Best Regards / Med vennlig hilsen
André Rømcke
System consultant & eZ Labs developer
eZ Systems Nordic
ar@... | [phone] | www.ez.no

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Sam Ruby-2]

I'm trying to understand the nature of the ES3.1 - ES4 subset
relationship that this committee has agreed to.

> p69 12.10.  Disallowing the with statement in strict mode breaks the
> ES3.1 - ES4 subset relationship (we've found no compelling reason to
> ban it).

How does having ES4 support *more* than ES3.1 supports break the
subset relationship?

- Sam Ruby
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Maciej Stachowiak]

On Jun 12, 2008, at 9:45 AM, Sam Ruby wrote:

> I'm trying to understand the nature of the ES3.1 - ES4 subset
> relationship that this committee has agreed to.
>
>> p69 12.10.  Disallowing the with statement in strict mode breaks the
>> ES3.1 - ES4 subset relationship (we've found no compelling reason to
>> ban it).
>
> How does having ES4 support *more* than ES3.1 supports break the
> subset relationship?

Having ES3.1 strict mode forbid features that ES4 strict mode does not  
(but which are in both languages) feels like breaking the subset  
relationship to me. The reason is that program that is purely ES3 but  
has the strict mode pragma added could then be legal in one language  
but not the other, which seems problematic.

To the extent that strict mode limits ES3-with-pragma programs, I  
think it should impose the same limits in ES3.1 and ES4.

Regards,
Maciej

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Lars Hansen-3]

Fair question.  I don't recall that it has been spelled out carefully,
actually.  I'll take a stab at it in the morning.  (Also, the ES3 ->
ES3.1 and ES3 -> ES4 relationships are important.)  Any useful
definition will have to deal with bugfixes and security fixes (like
global type names being read-only under some circumstances in ES4).

--lars

> -----Original Message-----
> From: sa3ruby@... [mailto:sa3ruby@...] On Behalf
> Of Sam Ruby
> Sent: 12. juni 2008 18:46
> To: Lars Hansen
> Cc: es3.x-discuss@...; es4-discuss@...
> Subject: Re: ES3.1 Draft: 11 June 2008 version available
>
> I'm trying to understand the nature of the ES3.1 - ES4 subset
> relationship that this committee has agreed to.
>
> > p69 12.10.  Disallowing the with statement in strict mode breaks the
> > ES3.1 - ES4 subset relationship (we've found no compelling
> reason to
> > ban it).
>
> How does having ES4 support *more* than ES3.1 supports break
> the subset relationship?
>
> - Sam Ruby
>

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Mark S. Miller-2]

On Thu, Jun 12, 2008 at 9:45 AM, Sam Ruby <rubys@...> wrote:
>> p69 12.10.  Disallowing the with statement in strict mode breaks the
>> ES3.1 - ES4 subset relationship (we've found no compelling reason to
>> ban it).


Regarding whether there's a compelling reason to ban "with", what
about the issue that "with" is an insanely confusing construct?

On the spreadsheet, how much red was accumulated on "strict with"?
IIRC, it was a lot. Does anyone think "with" is a valuable construct?
Why? Anyone care to post a defense of "with"?

--
    Cheers,
    --MarkM
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Brendan Eich-2]

On Jun 13, 2008, at 10:11 AM, Mark S. Miller wrote:

> On Thu, Jun 12, 2008 at 9:45 AM, Sam Ruby <rubys@...> wrote:
>>> p69 12.10.  Disallowing the with statement in strict mode breaks the
>>> ES3.1 - ES4 subset relationship (we've found no compelling reason to
>>> ban it).
>
>
> Regarding whether there's a compelling reason to ban "with", what
> about the issue that "with" is an insanely confusing construct?

The horse has left the barn.


> On the spreadsheet, how much red was accumulated on "strict with"?

"Reformed with" was an attempt to restore lexical scope by exact type  
annotation. That's what people voted down, not the ES1-3 "with"  
statement.


> IIRC, it was a lot. Does anyone think "with" is a valuable construct?
> Why? Anyone care to post a defense of "with"?

There's no point tilting at windmills. "with" is absolutely required  
for web compatibility, and it won't go away for a long, long time --  
if ever. It's insanely popular. It's not only common in extant or  
"legacy" JS, new uses crop up all the time.

You might hope to cause "with" to go away by forbidding it in a new,  
optional ES3.1 mode, but the chances of that seem at least as small  
as the chances that "with" popularity will simply make people avoid  
such a strict mode.

/be

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Mark S. Miller-2]

On Fri, Jun 13, 2008 at 10:21 AM, Brendan Eich <brendan@...> wrote:
> "Reformed with" was an attempt to restore lexical scope by exact type
> annotation. That's what people voted down, not the ES1-3 "with" statement.

I'm confused. Aren't we talking about "reformed with"? What other
"with" do people imagine is compatible with strict mode? I must have
missed something.


--
    Cheers,
    --MarkM
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Lars Hansen-3]

> -----Original Message-----
> From: es4-discuss-bounces@...
> [mailto:es4-discuss-bounces@...] On Behalf Of Mark S. Miller
> Sent: 13. juni 2008 19:30
> To: brendan@...
> Cc: es3.x-discuss@...; es4-discuss@...
> Subject: Re: ES3.1 Draft: 11 June 2008 version available
>
> On Fri, Jun 13, 2008 at 10:21 AM, Brendan Eich
> <brendan@...> wrote:
> > "Reformed with" was an attempt to restore lexical scope by
> exact type
> > annotation. That's what people voted down, not the ES1-3
> "with" statement.
>
> I'm confused. Aren't we talking about "reformed with"?

Dead for a long time, now.

> What
> other "with" do people imagine is compatible with strict
> mode? I must have missed something.

The one in ES3.  What makes it not compatible with strict mode?

--lars
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Mike Cowlishaw]

> Regarding whether there's a compelling reason to ban "with", what
> about the issue that "with" is an insanely confusing construct?

Compared to many other notations that language standards committees
consider 'non-controversial' (such as using '*' to mean multiply and
'curly braces' for essential grouping) this would seem to be a very mild
insanity.

Mike





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Mark Miller-2]

On Fri, Jun 13, 2008 at 11:20 AM, Lars Hansen <lhansen@...> wrote:
>> What
>> other "with" do people imagine is compatible with strict
>> mode? I must have missed something.
>
> The one in ES3.  What makes it not compatible with strict mode?

Doesn't it make static scope analysis impossible?


--
Text by me above is hereby placed in the public domain

 Cheers,
 --MarkM
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss