Bug 20653 - need a way for Web Components to cause new interface objects to exist dynamically
Summary: need a way for Web Components to cause new interface objects to exist dynamic...
Status: NEW
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 20493
  Show dependency treegraph
 
Reported: 2013-01-12 00:26 UTC by Dimitri Glazkov
Modified: 2013-08-05 15:53 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitri Glazkov 2013-01-12 00:26:08 UTC
ES5 says all function objects need to have it:

http://ecma-international.org/ecma-262/5.1/#sec-13.2

We should too, right? http://www.w3.org/TR/WebIDL/#dfn-function-object
Comment 1 Cameron McCormack 2013-01-12 00:36:55 UTC
Yes, although most uses of "function object" in the spec define a prototype (and length) property for them, at least the one mentioned in http://dev.w3.org/2006/webapi/WebIDL/#es-environment does not.  Also, the note in http://dev.w3.org/2006/webapi/WebIDL/#interface-object assumes that by linking to #dfn-function-object it means that it will already be required to have "prototype" property, which isn't true.
Comment 2 Allen Wirfs-Brock 2013-01-12 01:04:00 UTC
But note that even in ES5, built-in functions don't have a prototype property and are not usable as constructors (they do not have a [[Construct]] internal method).  

In ES6, functions syntactically defined as methods (concise methods in object literals and class definitions) also will not have a prototype property and are not usable as constructors. 

I think it would be fine for WebIDL to treat all method like functions in the same manner as ES6 concise methods.
Comment 3 Cameron McCormack 2013-01-12 01:10:54 UTC
That is interesting to know.  Once we recast Web IDL's ES requirements in terms of ES6, we should look at which functions don't need to be constructable like this.
Comment 4 Boris Zbarsky 2013-01-12 01:12:42 UTC
Indeed.  And there are certainly plenty of prototype-less Functions around right now in WebIDL too:

[20:09:43.043] Object.getOwnPropertyDescriptor(Array.prototype.push, "prototype")
[20:09:43.045] undefined
--
[20:09:52.795] Object.getOwnPropertyDescriptor(document.getElementById, "prototype")
[20:09:52.797] undefined

compared to:

[20:11:44.744] Object.getOwnPropertyDescriptor(EventTarget, "prototype")
[20:11:44.747] ({configurable:false, enumerable:false, value:{addEventListener:function addEventListener() {
    [native code]
}, removeEventListener:function removeEventListener() {
    [native code]
}, dispatchEvent:function dispatchEvent() {
    [native code]
}}, writable:false})

What we sorta want is a place defining interface objects that Web Components can link to....
Comment 5 Boris Zbarsky 2013-01-12 01:14:04 UTC
But yes, the note that claims that being a function object implies having a .prototype property in #interface-object doesn't make that much sense to me.
Comment 6 Cameron McCormack 2013-08-04 06:59:20 UTC
OK, so it looks like there aren't any cases in the spec where we're defining a “prototype” property where we shouldn't be.

(In reply to comment #4)
> What we sorta want is a place defining interface objects that Web Components
> can link to....

Got a link to the Web Components spec where this is needed?
Comment 7 Dimitri Glazkov 2013-08-05 15:53:40 UTC
(In reply to comment #6)

> Got a link to the Web Components spec where this is needed?

Here's the spec:

https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html

Here's the place where we generate a constructor:

https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#dfn-custom-element-constructor-generation