global function declarations and predefined global properties

Mark S. Miller erights at google.com
Wed Jul 7 17:39:47 PDT 2010


On Wed, Jul 7, 2010 at 5:15 PM, Allen Wirfs-Brock <
Allen.Wirfs-Brock at microsoft.com> wrote:

>  The following issues were originally brought up on a Firefox bug report
> https://bugzilla.mozilla.org/show_bug.cgi?id=577325 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>
>
> <script type="text/javascript">
>
>    function foo() {alert("foo 2")};  //overwrites previous foo declaration
> from first script block
>
>    foo();  //this will display “foo 2”
>
> </script>
>
>
>
> <script type="text/javascript">
>
>    Object.defineProperyt(this, "foo", {get: function (){return function()
> {alert("foo 1")}}});
>
> </script>
>
> <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”
>
> </script>
>
>
>
>
>
> To me, the behavior for function undefined() {}; seems desirable.
>
Agreed.


> 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.



>
>
> Allen
>
>
>
> _______________________________________________
> es5-discuss mailing list
> es5-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es5-discuss
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es5-discuss/attachments/20100707/b831e9c4/attachment.html>


More information about the es5-discuss mailing list