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

Re: [WebIDL] A new way to define UnionTypes

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 29 Aug 2012 09:06:47 -0700
Message-ID: <CAJE5ia-KAoHJtusQXZe9vG3me3xb9e_DU6WvfKTdDcD03Amz5g@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: public-webapps@w3.org
On Wed, Aug 29, 2012 at 8:11 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 8/29/12 7:59 AM, Andrei Bucur wrote:
>> I was wondering if it would make sense to use supplemental interfaces as a
>> way to generate union types, like in this example:
>> X implements S
>> Y implements S
>> Z implements S
>> interface someInterface
>> {
>>         NewSyntaxGeneratingUnionTypeFrom(S) someMethod();
>> }
> Why can't you just do:
>  interface someInterface
>  {
>     S someMethod();
>  };
> ?
>> Having this syntax makes it easy to define functions that will definitely
>> return objects adhering to a certain interface but are not necessary
>> containing S in the prototype chain.
> Yes, that's the idea of "implements"...
>> A real life use case for this is the Region interface [1]. Right now, the
>> only interface implementing Region is Element. The plan is to also allow
>> pseudo elements [2] implement the Region interface. Because Element and
>> CSSPseudoElement are totally different types it is impossible to define a
>> method that returns a "Region" (e.g. NamedFlow.getRegions() [3]).
> Why is it impossible, exactly?  Just define it as returning a Region in the
> IDL.

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.

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

Received on Wednesday, 29 August 2012 16:07:47 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:45 UTC