297206 - objects constructed by Function can't be given a name property

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Jonathan Watt [:jwatt]]

When you construct a function using the Function object and subsequently assign
it a property called 'name', accessing this property still returns 'anonymous'.
It would be good if this would work so that debuggers could report the names of
functions constructed using Function.

javascript: var f = new Function(';'); f.name = 'f'; alert(f.name);

Comment 1

[Brendan Eich [:brendan]]

Function names are readonly, as are arities returned via the length property of
function objects.  The name property of function objects is a SpiderMonkey (also
perhaps Rhino, I haven't checked) extension to ECMA-262, allowed by Section 16
of Edition 3.  As with the length property, it's important to keep such
reflected internal properties readonly to uphold invariants, avoid sharing
hazards, and other kinds of incoherence.

The javascript: labeled line in comment 0 proposed an over-broad solution.  We
do not want the name property of function objects to be read/write -- rather, as
the summary requests, we want a way to created named function objects using the
Function constructor.  Awkward to do without named actual arguments (JS2), as
the Function constructor is defined to treat the first N-1 of N actual args as
formal parameter names, and treat the Nth actual as the function body.

A clean solution in light of this would be a NamedFunction or FunctionWithName
constructor, an extension to the global scope that goes along side Function.

/be

Comment 2

[Brendan Eich [:brendan]]

I want to push back on comment 0 more: who uses Function constructors, and why?
 Granted it's sometimes useful, what are the particular cases that motivated
filing this bug?

/be

Comment 3

[Jonathan Watt [:jwatt]]

If function names are readonly, it would be nice to get an error in the
JavaScript Console when you try to change them.

(In reply to comment #2)
> I want to push back on comment 0 more: who uses Function constructors, and why?
>  Granted it's sometimes useful, what are the particular cases that motivated
> filing this bug?

I'm not actually using the Function constructor. It just occured to me that if I
did, then there's no way to specify the resulting function's name. The only time
I can think of that Function might come in useful for me is if I need to create
a function that must exist outside of the scope in which it's created, but
without creating a closure. It seems less likely that I'll want to use Function
to dynamically create a function's parameters/body.

Comment 4

[Mike Shaver (:shaver emeritus)]

ECMA says that writing to read-only properties is a no-op, and not an error.  We
probably need to stick to that for the ECMA-defined objects, though I'm reminded
of a desire to see us put up an error for XPConnected objects.

We could emit a strict warning for assignment-to-readonly, I suppose.  Not sure
how I feel about that.

Comment 5

[Jonathan Watt [:jwatt]]

(In reply to comment #4)
> ECMA says that writing to read-only properties is a no-op, and not an error.

Really? It seems to me that causes a conflict between ECMAScript and the SVG
interface ECMAScript bindings. The SVG spec frequently requires
assignment-to-readonly to throw.

Comment 6

[Mike Shaver (:shaver emeritus)]

This textbox is too small to contain my full feelings about SVG's dedication to
compatibility with the standards on which it depends, but ECMA 262 Edition 3
seems pretty clear:

4.2 Language Overview

[...] for example, when the ReadOnly attribute for a property is set to true,
any attempt by executed ECMAScript code to change the value of the property has
no effect.

8.6.1 Property Attributes

ReadOnly

The property is a read-only property. Attempts by ECMAScript code to 
write to the property will be ignored.

8.6.2.2's step 2 also has it returning, rather than signalling error, if
[[CanPut]] returns false (as it will for a ReadOnly property as per 8.6.2.3 step 2).

Comment 7

[Jonathan Watt [:jwatt]]

Okay, I guess this bug is invalid then.

Any idea of the reasons why this is the behaviour prescribed by ES3? To me it
would seem more helpful to scripters if they get an error, else they're likely
to experience bugs in their code that are more difficult to track down.

Comment 8

[Brendan Eich [:brendan]]

(In reply to comment #7)
> Any idea of the reasons why this is the behaviour prescribed by ES3?

This goes back to Edition 1 of ECMA-262, it was a change urged by MS among
others.  The original Mocha runtime I implemented for Netscape 2, which also
shipped in Netscape 3, reported an error (no exceptions then).  Without the
ability to throw a catchable exception, ECMA TG1 reckoned that silent failure to
set a readonly property was better than an uncatchable error.

When Edition 3 added try/catch/finally, the group could have revisited this
decision, but apparently did not (I was not really involved at that point; busy
founding mozilla.org).  Compatibility was king, even though that argument did
not work to preserve all Netscape 2-era behavior.

> To me it
> would seem more helpful to scripters if they get an error, else they're likely
> to experience bugs in their code that are more difficult to track down.

I agree.  There are several cases, reference to an undefined property being
another one, that might have been better done throwing instead of silently
seeming to work, but it's too late for JS1.  For JS2 with a strict option that
makes things incompatbile, we can do better.

/be