Re: WebIDL extension proposal for [Enumerable] interface attribute

Hi Camron,

2009/7/10 Cameron McCormack <cam@mcc.id.au>:
> Anselm R Garbe:
>> Ok, another OT question: what is the reason behind the Java binding
>> focus of WebIDL?
>> I mean at least my primary focus is using WebIDL to express JS API
>> interfaces, and currently WebIDL is limited by Java restrictions in
>> that respect...
>
> DOM specifications have historically provided both Java and ECMAScript
> language bindings.  My aim for Web IDL is for it to be a language
> binding independent way of describing interfaces, but to allow tricky
> ECMAScript-specific things to be specified using extended attributes if
> necessary.  And personally, I’m involved in a projet that does use Java
> bindings for DOM specifications.

Ah I see.

>> >> The main idea behind the optional properties is that it allows to
>> >> *formally* define "usual" properties, that are expected to be
>> >> supported by an implementation, but must not. So it's a MAY, not a
>> >> MUST spec-wise. Your proposed approach isn't really better than our
>> >> current approach of having typedef Object Map, and using that Map type
>> >> for what we are after, because the "usual" properties supported can't
>> >> be specified in a formal way (they are specified in a comment block
>> >> instead).
>> >
>> > Am I right in thinking that all you need is a way to specify the type of
>> > one of these optional properties?
>>
>> No, I think I introduced the property term by accident in my last mail
>> because I mixed it together with attributes. The type doesn't play the
>> major role for me, it's more about to specify the key of an optional
>> attribute. Having said that, the value is totally implementation
>> dependent and wouldn't be specified (hence, there is really no final
>> attribute mapping to Java, all (optional) attributes we are after
>> would just give an idea of which keys are usually implemented by such
>> an object, without any guarantee of their existence. But of course
>> they could be checked through enumerating an actual object.
>
> OK.  So if the attributes are effectively optional, and you make no
> requirements on the type of their values, I’m not sure what you gain
> from having a formal specification of them beyond using named
> attributes.

The only gain is to enforce better documentation and
self-descriptiveness in such interfaces.

>> >> Also, as you stated, your approach doesn't allow enumerations of such
>> >> optional properties, which is our main requirement.
>> >
>> > You only need the properties that are supported on the object to be
>> > enumerated, yes?  Having an extended attribute that specifies that
>> > corresponding named properties are enumerated would solve this.
>>
>> Yes, however just to make it clear: what I'm after is just to have a
>> formal way to declare (optional) interface attributes in a WebIDL
>> rather than declaring them informally in a comment block. That's all
>> about it, really.
>
> To be clear, such optional interface attribute declarations wouldn’t
> actually entail any requirements on the implementation, right?  Unless

Yes.

> you want to give them types so that particular type conversions are made
> if those properties do exist on the ECMAScript object.

Ok, enforcing the declared type for the named attribute is fine with
me, if it's present. I think that's cleaner than what I initially
asked that even the type might differ in an implementation.

>> >> The conversion is up to the language binding implementation anyways,
>> >> so that would be easily able to synchronize between Hashtable and the
>> >> specified WebIDL interface in the case of a Java binding (even if
>> >> there are non-optional attributes). The same applies to most other
>> >> languages that support associative arrays in general.
>> >
>> > I didn’t understand this point, sorry.
>>
>> Well, I use WebIDL to define JS APIs. What I tried to say is that
>> binding some API specified in WebIDL to a language like Java shouldn't
>> result in limitations in the expressiveness of the IDL itself (that's
>> of course related to the question if Java has to be a constraint in
>> the WebIDL design). The implementation of the binding has to deal with
>> mapping from the IDL into the specific language.
>
> Right.  I am certainly open to extending the IDL language to support
> what you need.  I guess I am still not clear exactly what requirements
> of the ECMAScript language binding would need to be added, beyond having
> an extended attribute to say that corresponding named properties are
> enumerable.
>
>> >> The enumeration is especially a requirement for those properties that
>> >> aren't declared.
>> >
>> > Right, that’s what I suggest with [NamedPropertiesEnumerable].
>>
>> Ah ok, but as said earlier all I'm after is just a way to express
>> (optional) attributes in interfaces and to specify the enumeration of
>> them, not really with any particular language bindings in mind.
>
> Do you need to specify that some of the optional attributes are
> enumerable while others aren’t?  Or should all of the optional
> attributes be enumerable?

We only need to specify that all (optional) attributes are enumerable,
so basically that means we need something that says "all attributes of
this interface are enumerable, including the optional ones".

Kind regards,
Anselm

Received on Friday, 10 July 2009 08:45:39 UTC