- From: <bugzilla@jessica.w3.org>
- Date: Mon, 20 Jun 2011 05:18:53 +0000
- To: public-script-coord@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8241
Brendan Eich <brendan@mozilla.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |brendan@mozilla.org
--- Comment #12 from Brendan Eich <brendan@mozilla.org> 2011-06-20 05:18:52 UTC ---
(In reply to comment #11)
> In the Firefox, case at least, I think part of your problem is that you're
> lumping together _different_ sorts of named properties. In particular frame
> names are treated quite differently from properties that come from the global
> scope polluter in Gecko; I can't speak to other browsers.
>
> The exact Gecko name resolution process on Window is:
>
> 1) Something with standard classes (Object, Array, etc). Not quite sure what
> and how those interact with named frames and the like.
> 2) Look for a named frame with that name.
This is a decision tree (skinny, one path only, so a list). Since (2) comes
after (1) we can be sure that buitl-ins (standard classes such as Object) are
resolved in preference to frames of the same name. Of course frame indexes
cannot name any built-in in ECMA-262, so those are resolved in a step (0).
Also, there is a step (1.5) where 'constructor' is handled specially, so that a
frame with that name cannot shadow the prototype property of that name on
Window. I'm not sure this is anything but a historical accident, though.
Re: comment 10: it is important for integrity and optimizability that
var-defined bindings be non-configurable.
/be
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Monday, 20 June 2011 05:18:59 UTC