W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: [WebIDL] A new way to define UnionTypes

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 29 Aug 2012 12:31:17 -0400
Message-ID: <503E43D5.4030403@mit.edu>
To: Adam Barth <w3c@adambarth.com>
CC: public-webapps@w3.org
On 8/29/12 12:06 PM, Adam Barth wrote:
> It's not impossible in IDL.  In fact, it's remarkably easy to define
> in IDL.  We just don't want to implement multi-inheritance in WebKit
> because it's slow.  However, I don't see how Andrei's proposal makes
> the implementation any more efficient.

Well, polymorphism is polymorphism, whether you implement it as a tagged 
union or virtual dispatch or whatever.  Nothing in the IDL requires that 
you use any particular implementation strategy, so I'm not sure why 
we're talking about the IDL if the worry is implementation.  For 
example, a WebIDL implementation already knows all the interfaces that 
appear on the LHS of "implements" with S on the RHS, and could use 
tagged unions under the hood if it wanted to.  No need for new IDL 
syntax here if this is a purely implementation concern.

Unless you're going to argue for removal of "implements" from the web 
platform, you'll pretty much have to come up with a way to handle it, by 
the way...

> Note: Gecko already pays this implementation cost because XPCOM
> support queryInterface.  We'd rather not add queryInterface to WebKit.

For what it's worth, for WebIDL return values that are the RHS of 
"implements" in Gecko I don't plan to use either XPCOM or 
QueryInterface.  There'll just be one extra virtual function call (with 
a cheap implementation) compared to the normal return-value codepath 
(though some are arguing for a tagged-union approach as described above, 
I suspect the complexity won't be worth it; the one advantage of the 
tagged union is not needing an extra vtable pointer word in the 
element).  It's some overhead for sure, but that's polymorphism for you.

-Boris
Received on Wednesday, 29 August 2012 16:31:57 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:54 GMT