This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 14813 - Prototype of interface objects is Object.prototype in implementations, not Function.prototype
Summary: Prototype of interface objects is Object.prototype in implementations, not Fu...
Status: CLOSED WONTFIX
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: All All
: P2 minor
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-13 17:23 UTC by Aryeh Gregor
Modified: 2011-12-27 15:31 UTC (History)
6 users (show)

See Also:

Attachments

Description Aryeh Gregor 2011-11-13 17:23:44 UTC 
4.5.1: "Interface objects are always function objects."

4: "If an object is defined to be a function object, then it has characteristics as follows:

* Its [[Prototype]] internal property is the Function prototype object."

data:text/html,<!doctype html>
<script>
alert(Object.prototype.isPrototypeOf(Node));
alert(Function.prototype.isPrototypeOf(Node));
</script>

alerts "true", then "false" in all browsers tested: IE9, Firefox 9.0a2, Chrome 16 dev, Opera 12.00.  (I wasn't able to double-check in IE9 right now, but I believe its behavior matches too.)  WebIDL needs to define that the prototype of interface objects is Object.prototype, not Function.prototype, unless I'm missing something.
Comment 1 Aryeh Gregor 2011-11-13 17:35:54 UTC 
Double-checked in IE9, same behavior.
Comment 2 Yehuda Katz 2011-11-13 22:11:45 UTC 
On the other hand, trying to `new` a Node, gives "Illegal constructor", not "object is not a function".
Comment 3 Brendan Eich 2011-11-13 22:30:14 UTC 
(In reply to comment #2)
> On the other hand, trying to `new` a Node, gives "Illegal constructor", not
> "object is not a function".

Non-function objects can have [[Construct]] internal methods, too -- just not any defined by ECMA-262 itself that do not have [[Construct]]. So we could make new work if we wanted to.

/be
Comment 4 Aryeh Gregor 2011-11-14 18:01:12 UTC 
(In reply to comment #2)
> On the other hand, trying to `new` a Node, gives "Illegal constructor", not
> "object is not a function".

In WebKit.  Gecko throws "Foo is not a constructor" across the board, and Opera actually throws NOT_SUPPORTED_ERR for new Node().  Anyway, the exact exception type is not likely relevant to web compat, so this isn't a big deal either way.
Comment 5 Aryeh Gregor 2011-11-20 17:20:14 UTC 
The same goes for exception interface objects (4.9.1).
Comment 6 Travis Leithead [MSFT] 2011-11-21 17:49:06 UTC 
> WebIDL needs to define that the prototype of interface objects
> is Object.prototype, not Function.prototype, unless I'm
> missing something.

I thought this issue was previously discussed, and folks (browser vendors) generally agreed to switch to function for the interface objects? I suppose there are plans in the works for other browser vendors to switch to function in these cases, right?
Comment 7 Aryeh Gregor 2011-11-21 19:45:21 UTC 
I'm fine with browsers changing here, I just want the spec to match browsers.  I came across this discrepancy while writing WebIDL test-cases.  If browsers have agreed they intend to change, then this bug should be closed WONTFIX and I'll make my test-cases match the spec (so all browsers fail).

I think it would be helpful to note in the spec that that requirement is a proposed change and implementers should be on the lookout for compat issues, though, until we have one major browser shipping the change with no compat issues.

FWIW, Function definitely does make sense here, AFAICT.  Object doesn't match the usual ES pattern for how "classes"/prototypes work.  So I'm all behind browsers changing here instead of the spec, if they're willing to try.
Comment 8 Cameron McCormack 2011-12-09 05:23:49 UTC 
Having them be function objects is closer to natively defined classes, yes.  It also lets them respond to [[HasInstance]] without any hackery.  Having function objects with Object.prototype as their [[Prototype]] would be weird, so better to leave it as Function.prototype.

It was done in bug 12458.  You can see the thoughts of some implementors there.  I have not had pushback since bug 12458 comment 13, but it might be that the change was not publicised widely enough and people haven't tried implementing it to check compatibility just yet.
Comment 9 Cameron McCormack 2011-12-15 03:22:32 UTC 
WONTFIXing.  I believe implementors are on board.  Again I'm not adding a note here since I would rather call out all differences from existing, interoperable implementations than just this one or two.  If someone is willing to do the work gather this information I will happily include it in the spec.

Please indicate whether this resolution is satisfactory, thanks.
Comment 10 Aryeh Gregor 2011-12-27 15:31:55 UTC 
Fine by me.  Tests updated: http://dvcs.w3.org/hg/html/rev/34d6cfb3b3be