Re: [WebIDL] Simplify callbacks

On 11/8/11 2:51 PM, Olli Pettay wrote:
> On 11/09/2011 12:43 AM, Brendan Eich wrote:
>> On Nov 8, 2011, at 2:03 PM, Olli Pettay wrote:
>>
>>> On 11/08/2011 11:59 PM, David Flanagan wrote:
>>>> Its useful in *some* cases, but the vast majority of the cases,
>>>> developers just want to pass a function, not an object. I say make all
>>>> new APIs take a function only, and let developers use ES5
>>>> Function.prototype.bind() when they want to specify a method. That's a
>>>> lot easier than having to remember whether the appropriate property 
>>>> name
>>>> is handleMutations, transactionStarted, or sample.
>>>
>>> If you just want to pass function, you can. But since 
>>> implementations need to support useful { foobar: function() {}} 
>>> syntax anyway, why not be consistent and support it always.
>>
>> The problem is 'foobar' is not consistently defined as one name, or a 
>> set of names whose parts can be derived from an obvious set of rules.
>>
>>
>>> Also, IMO, { foobar: function() {} } is significantly easier to 
>>> understand than some prototype hackery.
>>
>> What prototype hackery?
>>
>>    (function (e) {...}).bind(o)
>>
>> involves no prototype hackery.
>>
>
> Ok, no prototype hackery. I misunderstood David's example.
>
> But I still don't understand why to make platform less consistent by
> not supporting { callback: function() {}} syntax everywhere.
> Web author doesn't need to use it, but can use it.
>
> =FunctionOnly issue has been discussed earlier, and for example
> during TPAC =FunctionOnly was removed from IndexedDB callbacks.
> Similarly it has been removed lately from some other specs.
Given the current WebIDL syntax, I agree that =FunctionOnly should 
probably be removed.  But Anne has proposed an alternative syntax that 
changes things pretty radically.  Under that new syntax, I think it is 
worth trying to force all new callbacks to be functions rather than 
trying to hold on to Java-style interface objects.

If spec authors (and spec consumers) still have to deal with callback 
interface definitions that define different method names for different 
callback types, then it doesn't seem to me that there is much point in 
Anne's proposal.

     David


>
>
>> /be
>>
>

Received on Tuesday, 8 November 2011 23:38:35 UTC