Re: [WebIDL] prototype chains, multiple inheritance, mixin interfaces

On Sun, Nov 21, 2010 at 1:06 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Fri, 19 Nov 2010, Jonas Sicking wrote:
>> >
>> > Wouldn't that result in two interfaces in Java? There really is only
>> > one interface here, it's just specified in two different places.
>>
>> Does that matter? Is Java an important enough use case that we need to
>> add special constructs just to keep the number of interfaces down?
>> Looking at SVG, it doesn't seem like Java people shy away from having
>> many interfaces.
>
> Stuff moves from one to the other as we deprecate stuff. If we use two
> different interfaces here, it means that later we will break code that
> uses this because a member changed from one interface to another. If we
> don't care about this, then we shouldn't pretend to actually cater to Java
> (and should remove the Java part of WebIDL), IMHO.
>
> (This is in fact already a problem of sorts since some stuff on
> HTML*Element has been moved to the deprecated HTML*Element interfaces in
> the HTML spec, so if anyone implement DOM2 HTML they would be affected.)

Is this something that Java developers have really asked for? I can't
recall seeing any such requests on neither this nor the
public-dom/public-webapi/public-webapps lists over the many years I've
followed them.

I don't care much I guess. Interfaces are ever changing anyway as new
versions of specs add to them. Pick two of: Having the implemented
interfaces line up with specs, not changing implemented interfaces,
implementing new specifications. This is a problem we faced in gecko
and the one we left out was "having implemented interface line up with
specs". (Future versions are also going to leave out "not changing
implemented interfaces").

>> Though really, i'm not sure what having all these interfaces buys you.
>
> It makes it easier to unambiguously define the members of these
> interfaces, since there's only one of each, rather than having two as in
> the obvious simpler presentation (flattening the two interfaces and having
> one of them just say "and this member does the same as that member" over
> and over).

As an implementor of specs, this doesn't feel like a disadvantage. In
fact, the IndexedDB spec got significantly easier to understand when
we got rid of these "micro interfaces" which broke out common
functions form otherwise different interfaces.

>> >> > and having a hierarchy get flattened (e.g.
>> >> > DedicatedWorkerGlobalScope and SharedWorkerGlobalScope vs
>> >> > WorkerGlobalScope).
>> >>
>> >> So in this case, a WorkerGlobalScope can be either a
>> >> DedicatedWorkerGlobalScope or a SharedWorkerGlobalScope, is that
>> >> right?
>> >
>> > Yes.
>>
>> You should be able to use the same solution as described above:
>>
>> class DedicatedWorkerGlobalScope {
>>   void postMessage(in any message, in optional MessagePortArray ports);
>>            attribute Function onmessage;
>> };
>> DedicatedWorkerGlobalScope implements WorkerGlobalScope;
>> DedicatedWorkerGlobalScope implements WorkerUtils;
>> DedicatedWorkerGlobalScope implements EventTarget;
>>
>> class SharedWorkerGlobalScope {
>>   readonly attribute DOMString name;
>>   readonly attribute ApplicationCache applicationCache;
>>            attribute Function onconnect;
>> };
>> SharedWorkerGlobalScope implements WorkerGlobalScope;
>> SharedWorkerGlobalScope implements WorkerUtils;
>> SharedWorkerGlobalScope implements EventTarget;
>>
>> interface WorkerGlobalScope {
>>   readonly attribute WorkerGlobalScope self;
>>   readonly attribute WorkerLocation location;
>>
>>   void close();
>>            attribute Function onerror;
>> };
>
> That would give the JS objects the wrong name (specifically, names that
> differ in dedicated vs shared worker contexts).

The fact that workers now have two different definitions of
WorkerGlobalScope seems bad to me. Different names seem better.

>> >> > So we likely still need [Supplemental]. There's also the weird
>> >> > magic does for e.g. WindowModal, where the Window "class" is
>> >> > different in different contexts; should that just be done in prose?
>> >>
>> >> What is meant by the “class” being different?
>> >
>> > Poor terminology. I mean that the object's interface as seen from code
>> > is different -- specifically, a Window created by showModalDialog()
>> > has two extra members in its instance of "Window", there's no extra
>> > interface around. I guess it doesn't much matter how we do this
>> > particular one since anyone implementing Window in Java is going to
>> > want to shoot themselves pretty regularly anyway; that interface is
>> > just bonkers.
>>
>> WebIDL aside this seems like a complicated situation. In ECMAScript,
>> would the prototype object be different in a showModalDialog-created
>> window from that of a "normal" window? Or would these extra properties
>> just appear as properties on the instance itself?
>
> Browsers differ in how they do this but my intent is the former.

Both from an implementation point of view, and from a js-author point
of view it seems better that prototype objects are the same in
different windows and that these properties show up on the instance
instead.


If people really think that we should keep [Supplemental] in order to
keep down the number of java interfaces, or to keep them more stable I
would be fine with that. But I'd like to make sure that this is
something that Java developers really need and want.

/ Jonas

Received on Monday, 22 November 2010 22:04:09 UTC