Re: WebIDL extension proposal for [Enumerable] interface attribute

Hi Cameron,

2009/7/3 Cameron McCormack <cam@mcc.id.au>:
> Cameron McCormack:
>> (OT: Btw. why is WebIDL using the attribute keyword instead of the
>> property keyword if the terminology calls it property?)
>
> They are different things.  “Named properties” are name-value pairs that
> are exposed on an object through a getter.  Attributes are those
> individual variables defined on an interface.  Both attributes and named
> properties are reflected in ECMAScript by having ES properties on a host
> object.

Ok I understand, I was rather talking about attributes then ;)

>> >  var m = getFileMetadata();
>> >  m.abc;        // Like calling getProperty("abc").
>> >  m.def = 123;  // Like calling setProperty("def", 123).
>> >  m.toString;   // This gets the value of the "toString" property from
>> >                // the Object.prototype object.
>>
>> Well, we used a similar approach so far, but honestly it looks very
>> complex and implicit to me. Especially the aspect that it may result
>> in different behavior among different language bindings, such as the
>> Java binding (see below).
>
> What you want has to result in different behaviour in Java, since Java
> objects can’t have an open-ended set of properties on objects like in
> ES.

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

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

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

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.

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

>> > The other thing it doesn’t get you is enumerability of the properties.
>> > Currently any corresponding named properties (i.e., properties that
>> > exist on the host object that correspond to a supported named property)
>> > are DontEnum.  I can add an extended attribute, say
>> > [NamedPropertiesEnumerable], for this.
>>
>> That wouldn't go far enough, because it would only enumerate the named
>> properties and for them it's rather pointless to be enumerable,
>> because they are known anyways due to their declaration in the WebIDL.
>
> I think you’re confusing named properties and attributes.  Attributes
> are things declared on an interface with
>
>  [readonly] attribute type name;
>
> while named properties are those things that are exposed by getters.
> Currently, properties on ES objects that correspond to attributes (and
> operations and constants) are enumerable, while those that correspond to
> named properties (the so-called “corresponding named properties”) are
> not.  The [NamedPropertiesEnumerable] I suggest above would make those
> 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.

Kind regards,
Anselm

Received on Friday, 3 July 2009 12:25:20 UTC