This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
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.
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.
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.
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....
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.
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?
(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
Custom elements seems to have solved this without any Web IDL changes.