W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2014

Re: Exotic OBJECT?

From: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Wed, 13 Aug 2014 10:28:43 -0700
Cc: es-discuss <es-discuss@mozilla.org>, public-script-coord@w3.org
Message-Id: <89F8AA15-5568-4C8C-A7F4-33E3BAEF057D@wirfs-brock.com>
To: Garrett Smith <dhtmlkitchen@gmail.com>

On Aug 13, 2014, at 8:46 AM, Garrett Smith wrote:

> 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.

It's built-in to the complete environment provided by the host which includes the ES engine.  For a host to provide such functions it has to have agreement with the ES engine on how to express and  install them.

> 
> The new meaning for "built-in function" that you mention doesn't match
> the term defined earlier in the spec: "built in object."
In 4.3.6 the qualifier "independent of the host environment" probably needs to go away.

> 
> "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.

What's native code? It's up to the implementation to decide how built-in functions that aren't ECMAScript function objects are implemented. Maybe its all layered on top of some other virtual machine.  "Native method" is a term that we have intentionally eliminated because of its high potential to carry unintended implications.

Similar, we eliminated the term "host method" because, from a semantic perspective, it doesn't matter if a method is provided by the ES engine or by the host using hooks provided by the ES engine. We don't want to imply that host-provided methods have any special semantic restrictions or capabilities..

Allen
Received on Wednesday, 13 August 2014 17:29:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:22 UTC