- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 18 Oct 2007 10:34:19 +0000 (UTC)
- To: Cameron McCormack <cam@mcc.id.au>
- Cc: Web APIs WG <public-webapi@w3.org>
- Message-ID: <Pine.LNX.4.62.0710181026310.19595@hixie.dreamhostps.com>
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. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 18 October 2007 10:34:29 UTC