- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Wed, 13 Aug 2014 08:46:55 -0700
- To: Allen Wirfs-Brock <allen@wirfs-brock.com>
- Cc: es-discuss <es-discuss@mozilla.org>, public-script-coord@w3.org
On 8/12/14, Allen Wirfs-Brock <allen@wirfs-brock.com> wrote: > > On Aug 12, 2014, at 7:52 PM, Garrett Smith wrote: > >> On 8/12/14, Allen Wirfs-Brock <allen@wirfs-brock.com> wrote: >>> >>> On Aug 12, 2014, at 2:17 PM, Garrett Smith wrote: >>> >>>> On 8/12/14, Allen Wirfs-Brock <allen@wirfs-brock.com> wrote: >> [...] > As long as addEventListener is implemented as a built-in function (whatever > that means for the implementation) then f.p.toString should be able to deal > with it. Now "built in" is overloaded. Built in objects are those which are supplied the ECMAScript implementation, independent of the host environment. A built in function is a built-in object that is a function. Method addEventListener is supplied by the host environment and is therefore not a built-in function. The new meaning for "built-in function" that you mention doesn't match the term defined earlier in the spec: "built in object." "The built-in function objects defined in this specification may be implemented as either ECMAScript function objects (9.2) whose behaviour is provided using ECMAScript code or as implementation provided exotic function objects whose behaviour is provided in some other manner." That looks like an attempt to describe functions that are implemented with native code, as described by CreateBuiltinFunction. CreateBuiltinFunction might be better named, such as CreateNativeFunction, to provide consistent, unambiguous terminology and which could also be used unambiguously for WebIDL platform objects. -- Garrett @xkit ChordCycles.com garretts.github.io
Received on Wednesday, 13 August 2014 15:47:26 UTC