[Bug 20225] don't allow overridden operations and attribute getters/setters to be invoked on descendant objects

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20225

--- Comment #9 from Boris Zbarsky <bzbarsky@mit.edu> ---
> I don't distinguish binding code from implementation code

I do, because the difference is web-detectable because it affects the ordering
of argument conversions (which can throw) and the execution of whatever special
check you're talking about.

> and some implementations don't have an explicit "binding" anyway.

Can you name one?  The ones I'm familiar with, both firsthand and secondhand do
have such a thing.  And WebIDL clearly defines that there's the code that gets
run before you call into the actual method implementation, and then there's the
method implementation.

> The check about whether it's an HTMLCollection or HTMLPropertiesCollection has
> to be somewhere.

Why?

If you have an object whose proto chain includes HTMLCollection.prototype, why
exactly do the methods from that prototype not Just Work on that object?  If
it's really different enough that this is the case, I would argue it shouldn't
have that prototype on its proto chain.

> Whether it's in the implementation of the method or the binding, it's the same
> cost

This happens to not be true in any of the binding systems I've seen.

It's trivial to do in the implementation of the method, because in the method
your can have the HTMLCollection.prototype.namedItem method have a quick way to
check what object it's working on and HTMLPropertiesCollection objects 

> in theory, one pointer comparison

I don't see how, but please do feel free to enlighten me.

> I mean that it would mean that every time an interface wants to specialise a
> base class' behaviour

Why exactly would it want to do that?  That's the part I don't get.  If you
want a different behavior from the other thing, why are you inheriting from the
other thing?

In particular, in this case the HTMLCollection behavior is that namedItem()
returns null for unsupported names.  You seem to want to override that with a
namedItem which never returns null (except is declared as returning null
sometimes in the IDL?), right?  Why, exactly?  And if you _do_ want your
behavior to be that different, in what sense are you an HTMLCollection?  Just
so you can reuse its dynamic updating behavior definition?

My point is that this sort of random overriding is bad enough API design that
we _should_ be making it hard to write specs like this.  In my opinion.

> the spec would have to define what the superclass' method would do when
> applied to a subclass

Yes, and that seems fine to me, personally.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Friday, 7 December 2012 02:15:08 UTC