global function declarations and predefined global properties

Allen Wirfs-Brock Allen.Wirfs-Brock at
Wed Jul 7 18:20:44 PDT 2010

Yes, the second also throws in strict mode.  I just didn't bother to mention it.

From: Mark S. Miller [mailto:erights at]
Sent: Wednesday, July 07, 2010 5:40 PM
To: Allen Wirfs-Brock
Cc: es5-discuss at
Subject: Re: global function declarations and predefined global properties

On Wed, Jul 7, 2010 at 5:15 PM, Allen Wirfs-Brock <Allen.Wirfs-Brock at<mailto:Allen.Wirfs-Brock at>> wrote:
The following issues were originally brought up on a Firefox bug report but it raises questions of broader interest.

The basic user facing issues are:

1)  when a global function declaration is processed whose function name is the same as an already existing accessor property of the global object which of the following should happen:
   a) the set function of the accessor property is called with the function object as its argument
   b) the accessor property is redefined as a data property whose value is the function object

2)  when a global function declaration is processed whose function name is the same as an already existing property of the global object,  how do the attributes of the existing property affect the declaration:
   a) The pre-existing attributes are preserved, a pre-existing [[Writable]] attributes controls whether or not the value of the property actually changes
   b)  The pre-existing attributes are ignored and the attributes are unconditionally reset to {writable: true, enumerable: true, configurable: true}

For both 1) and 2) the ES5 spec. says that a) is the standard behavior.  The ES3 spec. explicitly says b) is the standard behavior for 2).  Because accessor properties didn't exist in ES3, 1) really doesn't apply there but the language of ES3 regarding function declarations could be reasonably interpreted as also requiring b) in that case.  Also, because ES3 doesn't have user specified attribute values 2) can only occur in ES3 WRT built-in global properties.

The above bug report raises the question of whether the changes from the ES3 spec. were intentional and also  are they desirable.

Note that for user global code, there are two ways that either of these situations could arise:
   1) the property named by the function declaration is the same as a built-in or otherwise predefined global property
   2) there are two or more Programs (html script tags) and the first one to be processed uses Object.defineOwnProperty on the global object to define a property while the second Program contains a FunctionDeclaration for the same name.

Some examples, using the ES5 specification:
   function undefined() {};
will silently do nothing (or in strict mode throw a ReferenceError) because undefined is a built-in with {writable: false, configurable: false}

Won't it throw a TypeError?

<script type="text/javascript">
   function foo() {alert("foo 1")};
<script type="text/javascript">
   function foo() {alert("foo 2")};  //overwrites previous foo declaration from first script block
   foo();  //this will display "foo 2"

<script type="text/javascript">
   Object.defineProperyt(this, "foo", {get: function (){return function() {alert("foo 1")}}});
<script type="text/javascript">
   function foo() {alert("foo 2")};  //will call default set function and do nothing
or in strict mode throw a TypeError.

   foo();  //this will display "foo 1"

To me, the behavior for function undefined() {}; seems desirable.

The behavior for the accessor example is less desirable but consistent with the semantics of accessor properties.
I agree that it is consistent. I don't see what's less desirable about it. Note my addition above, that your second redefinition does also throw in strict code as does your first.

Anyone have any additional thoughts on this.  Is there something broken here that needs to be fixed or is just another little oddity of our favorite programming language?
I don't see what the problem is. ES5 has many remaining oddities but I wouldn't count this as one of them. By contrast, I would consider #1b an oddity and #2b an unacceptable bug.


es5-discuss mailing list
es5-discuss at<mailto:es5-discuss at>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es5-discuss mailing list