W3C home > Mailing lists > Public > public-webapi@w3.org > April 2008

[Bindings] interfaces flattening

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 11 Apr 2008 04:49:12 +0000 (UTC)
To: public-webapi@w3.org
Message-ID: <Pine.LNX.4.62.0804110439230.7575@hixie.dreamhostps.com>


There are two use cases for interface flattening that I think it would be 
useful for the Web IDL spec to address.

Some interfaces are huge and are defined in various places, but should 
look, to authors, as if they were one coherent interface. For example, the 
Window object has bits added to it by all kinds of specs. HTML5 alone 
defines at least two interfaces that should really all just be Window.

It would be nice if there was a way of saying, when defining an interface, 
that really that interface should be merged into a more "real" one. For 
example:

   interface Window {
     // the "real" Window is defined here
     // ...
   };

   // In another spec:

   [Supplement] interface Window {
     // the members defined here act as if they were
     // defined on the real Window object
   };


There are also some interfaces, like Command in HTML5, and possibly like 
the URI decomposition attributes in HTML5, that aren't really interfaces, 
they're just defined in one place for convenience but really should be 
copy-and-pasted into a bunch of different (and practically unrelated) 
interfaces. Here again, the spec arrangement is intended to be convenient 
for readers of the spec, but needs to not affect the actual platform.

It would thus be nice if there was a way of saying, when defining an 
interface, that really another interface needs to be imported in. For 
example:

   [NoInterfaceObject] interface Utilities {
     // various members defined here
     // these will be exposed on various objects
     // independent of each other
   }

   [Import=Utilities] interface Tools {
     // this interface should act as if the members
     // of Utilities were just pasted in here
     // (with any members that are also implemented
     // by Tools shadowing those in Utilities)
   }


There are two related cases. One is objects that implement multiple 
interfaces that are available "using binding-specific casting methods", 
as, for instance, EventTarget. Another is inheritance, e.g. the way 
HTMLAnchorElement inherits from HTMLElement. The latter is supported in 
IDL. The former currently doesn't really easily fit into JS, it would be 
nice if it could be made somehow more consistent (e.g. so that you could 
override the EventTarget methods and affect all objects that implement 
EventTarget at once).

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 11 April 2008 04:50:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 11 April 2008 04:50:22 GMT