Re: [Bindings] extended attribute for callback function interfaces?

On Thu, 18 Oct 2007, Cameron McCormack wrote:
> Ian Hickson:
> > Our conclusion was that we would like a way to mark an interface as 
> > being a callback and thus implementable as a function, with the interface 
> > having one method, that method defing the signature of the function. Such 
> > interfaces should, in addition, not be exposed on the global object in JS.
> 
> Why would you want an interface object not exposed on the global object 
> for these callback interfaces?  Firefox at the moment does have an 
> EventListener interface object; Opera and WebKit don’t.

You wouldn't want it there because it would be useless.


> For HTML 5 peculiarities, perhaps an [InhibitInterfaceObject] or 
> something could be a more general solution.

That would be good, yes, though then we'd need two, one for that and one 
to indicate that the interface should be Function-implementable.


On Thu, 18 Oct 2007, Cameron McCormack wrote:
> >
> > It doesn't make much sense for interfaces that aren't callback 
> > interfaces.
> 
> It seems to me to make as much sense as being able to implement such 
> non-callback interfaces with an object with properties.

Oh no, having:

   myImageData = { width: 1, height: 1, data: [0, 0, 0, 0] };

...makes much more sense than having:

   myCanvasGradient = function (offset, color) { ... };

In fact, CanvasGradient is the perfect example of why we don't want 
Function to be randomly implementing interfaces. Then again, it's actually 
a good reason for not making any interface implementable by Object in JS 
too... can we have another attribute to stop that too? :-)


> > Also, interfaces that are expected to get more functions added in 
> > later versions would seem bad to make implementable as a function as 
> > the behavior would get very confusing when the later version of the 
> > spec is implemented.
> 
> I don’t think it would be confusing.  If you had
> 
>   interface A {
>     void f1(in Callback c);
>   };
> 
>   interface Callback {
>     void f2();
>   };
> 
> and in script:
> 
>   var a = …; // some object that implements A
>   var c = function() { … };
>   a.f1(c);
> 
> If Callback got another method later on, you’d get a TypeError saying 
> that ‘c’ didn’t implement Callback.  So you’d need to change it 
> to an object with two properties.
> 
> But even if you were using the other way of implementing Callback:
> 
>   var a = …; // some object that implements A
>   var c = { f1: function() { … } };
>   a.f1(c);
> 
> then if Callback got another method later on you’d still have the same 
> problem; ‘c’ doesn’t implement Callback.  So you still need to 
> make a change.

...except that your code would still work. The latter shouldn't raise a 
TypeError. We can't ever make the latter raise a TypeError, as that would 
be breaking back-compat with legacy code, by that point.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'