Re: [TreatNonCallableAsNull] alternative?

Cameron McCormack:
>> Regardless, I don't think we want to allow [TreatNonCallableAsNull]
>> behaviour elsewhere. It's not consistent with how type conversion is
>> done elsewhere.

Anne van Kesteren:
> Okay, so you
>
> 1. Only want to use [TreatNonCallableAsNull] for event handler attributes

Yes.

> 2. Favor consistency of type conversion over event handler attribute
> consistency

When it comes to using [TreatNonCallableAsNull] for things other than 
event handler attributes, yes.

> I and some others argue for
>
> A. Only want to use [TreatNonCallableAsNull] for event handler attributes
> B. Favor consistency of event handler attributes

Consistency among event handler attributes?  That's my preference too. 
But not Boris'.

Anyway, the strongest objection I have in this issue is against the use 
of [TreatNonCallableAsNull] for things other than event handler 
attributes.  My opinion on whether [TreatNonCallableAsNull] should be 
used only for specific event handler attributes or for all of them is a 
weak one.

> So it seems we both only want [TreatNonCallableAsNull] for event handler
> attributes, but the disagreement is about whether all event handler
> attributes should be the same IDL-wise. So lets focus on that (maybe
> issue a CfC?) because I think it would be really great if
>
> [TreatNonCallableAsNull] attribute Function? oncanplaythrough;
>
> [Callback=FunctionOnly, NoInterfaceObject]
> interface Function {
> any call(any... arguments);
> };
>
> could become
>
> eventhandler oncanplaythrough;
>
> with "eventhandler" being a defined type in IDL reserved for members
> starting with "on" having equivalent semantics to other members starting
> with "on" throughout the platform.

[Callback=FunctionOnly] is gone from the spec, so what you currently do 
have to write is:

   callback Function = any (any... arguments);
   typedef [TreatNonCallableAsNull] Function? eventhandler;

in one place, say DOM Core, and then all definitions of event handler 
attributes can become

   attribute eventhandler onblah;

I am sympathetic to having

   callback Function = any (any... arguments);

built-in, in fact I would be happy to include that to the Common 
Definitions section at the bottom of the spec, if you like.

> On top of that you still need the boilerplate language from HTML (which
> cannot move to DOM last time I checked because some dependencies), but
> at least the IDL will look clean, [TreatNonCallableAsNull] will not
> accidentally be used elsewhere, and one-time typedef's are not needed
> either.

I don't see what's so bad about the one-time typedef.  Typedefs exist to 
avoid repetition like that!

Defining "eventhandler" as a built-in type in the IDL just seems like an 
abstraction violation to me.

Received on Tuesday, 6 March 2012 23:51:08 UTC