- From: liorean <liorean@gmail.com>
- Date: Sun, 23 Sep 2007 03:48:13 +0200
- To: public-webapi@w3.org, "WHAT Working Group Mailing List" <whatwg@whatwg.org>
On 22/09/2007, Garrett Smith <dhtmlkitchen@gmail.com> wrote:
> Host objects are not quite javascript objects, so it wouldn't be an
> override of Object.prototype. AFAIK, Host objects are not req'd to
> support Object.prototype.
>
> In Gecko, these host objects are either very well duck typed, or they
> are integrated into the JS engine well enough as to make them nearly
> indistinguishable. In JScript, host objects are not quite so well duck
> typed. You cannot, for example, say document.body.appendChild.call(
> document.body, node ). And try document.body.toString() that is really
> weird.
Try to add another layer of indirection.
Function.prototype.call.call(document.body.appendChild,document.body,node);
The DOM interfaces and instances aren't JScript objects, they strictly
speaking don't partake in the appropriate ECMAScript prototype chain
and other ECMAScript specific semantics, but they generally cooperate
with the ECMAScript environment if you just avoid using ECMAScript
specific semantics on the COM objects directly.
That said, JScript fails to make a *lot* of things work seamlessly.
The DOM and other COM interfaces really don't integrate and behave
very ECMAScripty at all. But if you scratch at the surface, you will
find that in any browser, the barrier beween underlying application
programming interfaces and ECMAScript interfaces is just evident in
different places.
--
David "liorean" Andersson
Received on Sunday, 23 September 2007 01:48:23 UTC