Re: WebIDL extension proposal for [Enumerable] interface attribute

Hi Anselm.

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.

> >> 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.

> >> 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
you want to give them types so that particular type conversions are made
if those properties do exist on the ECMAScript object.

> I think you understand my requirement more in a way to help us with
> the language bindings -- but we just use WebIDL to specify JS APIs, we
> don't use WebIDL directly for any language bindings in that respect.

Understood.

> >> 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?

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Friday, 10 July 2009 06:05:46 UTC