jyasskin
2015-04-24
WebIDL provides 3 ways to say that a set of members listed in one place appears on an interface defined in another place:
interface SomeMembers {
DOMString getStuff();
};
interface DefinedElsewhere : SomeMembers {};
interface MoreMembers {
long otherStuff();
};
DefinedElsewhere implements MoreMembers;
partial interface DefinedElsewhere {
Promise<void> yetAnotherMember();
}
It’s not clear to me how to decide which of these to use in any given situation. Here’s what I have so far:
- Inheritance leads to a JavaScript prototype chain, which might cost time in each call, but might save space if the base class is inherited from many times.
- It’s only possible to inherit from a single other interface, so this doesn’t scale if you want to pull members from several other places.
- A
partial interface
doesn’t work well if you have several related methods you want to put in multiple places. For example, you’d have to list methods twice to add them to bothWindow
andWorkerGlobalScope
with apartial interface
, but you could write that list just once if you added them withimplements
. -
implements
makes you come up with a name for the implemented interface, whichpartial interface
doesn’t.
These seem to add up to the following guidelines:
- Use
partial interface
when you’re adding fields to only 1 interface, or you’re adding only 1 simple field to multiple interfaces. - Use
implements
otherwise.
What all am I missing?
Does anyone have better guidelines?