On Feb 9, 2009, at 6:29 PM, Waldemar Horwat wrote:
Brendan Eich wrote:
I’ve tried various formulation of a simple statement about host
objects but I keep finding potential holes and coming back to the
conclusion that the only meaningful thing to do is to explicitly
enumerable the
On Feb 10, 2009, at 1:52 PM, Brendan Eich wrote:
* has a .length property that can be set to a lesser value than its
current value to truncate or extend the set of indexed properties
(not all would-be arraylikes can be truncated or extended in my
experience).
s/lesser/different/
/be
On Tue, Feb 10, 2009 at 1:52 PM, Brendan Eich bren...@mozilla.com wrote:
I'm against such ontological confusion :-P.
Me too!
[...] I'm not sure how the spec would even talk about such implementations,
other than by doing what Allen said and requiring indistinguishability from
native
On Tue, Feb 10, 2009 at 2:49 PM, Allen Wirfs-Brock
allen.wirfs-br...@microsoft.com wrote:
I guess it is time for one of my alternative lists.
Good. Thanks!
The original question was what if any restrictions should ES3.1 place upon
host objects' [[Class]] values. The alternatives on the
Mark Miller said: We can get the effect of specifying such
indistinguishability simply by specifying that host objects may have as their
[[Class]] property Object, or any string not otherwise used by the spec as a
[[Class]] value.
I generally agree, but I have two what about's that actually
2009/2/10 Allen Wirfs-Brock allen.wirfs-br...@microsoft.com
Mark Miller said: We can get the effect of specifying such
indistinguishability simply by specifying that host objects may have as
their [[Class]] property Object, or any string not otherwise used by the
spec as a [[Class]] value.
Are there implementations that throw it? I thought there was at least one.
Waldemar
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I've been told that Opera does (or at least did). However, Opera 9.63 on
windows doesn't appear to. Maybe it's the mobile version that does it.
Regardless, the clarification of the semantic difference between direct and
indirect eval arguably makes the optional disallowance of indirect eval
I don't see why a host object would claim [[Class]] == Object -- we
have custom classes throughout our DOM, so do others, but if you want
an object whose [[Class]] == Object, you want an instance of the one
true native Object constructor.
The issue with host objects wanting to claim
Chris Pine answered this one recently:
https://mail.mozilla.org/pipermail/es-discuss/2009-January/008697.html
/be
On Feb 10, 2009, at 6:27 PM, Allen Wirfs-Brock wrote:
I've been told that Opera does (or at least did). However, Opera
9.63 on windows doesn't appear to. Maybe it's the mobile
Good, so back to the original questions.
Do we remove the current permission to throw EvalError? [I vote yes]
Once it's gone what do we do with the EvalError object? [I vote leave it in the
spec. with a note that says it isn't currently used and exists for
compatibility with previous ES
Waldemar's Mountain View notes said: - Agreed to disallow the use of eval as
the name of a local variable, function parameter, etc. in strict mode.
Did we really mean that only function scoped declarations are so restricted?
What about var declarations in strict global code?
What about
On Tue, Feb 10, 2009 at 6:42 PM, Allen Wirfs-Brock
allen.wirfs-br...@microsoft.com wrote:
Good, so back to the original questions.
Do we remove the current permission to throw EvalError? [I vote yes]
Once it's gone what do we do with the EvalError object? [I vote leave it in
the spec.
On Tue, Feb 10, 2009 at 7:50 PM, Allen Wirfs-Brock
allen.wirfs-br...@microsoft.com wrote:
However, now that I think a little bit more about, it would be reasonable
to say that any strict mode declaration of eval is an EvalError. I was
going to say it was a SyntaxError but EvalError is more
On Feb 10, 2009, at 9:15 PM, Allen Wirfs-Brock wrote:
Mark Miller: I like your #2 direction a lot. If it were feasible to
require that host objects not even use [[Class]] Object, I'd be in
favor. However, I'm guessing that would differ too greatly from
current browser behavior to have a
15 matches
Mail list logo
