Re: WebIDL extension proposal for [Enumerable] interface attribute

Hi Anselm.

Cameron McCormack:
> > I think you should define this instead using named properties.  It
> > doesn’t seem to be useful to define an interface that has attributes
> > with particular names and types if they might not exist at all (or might
> > exist but be different types).

Anselm R Garbe:
> I think it's not a strong requirement of having an optional property
> that appears with a different type, it's more a consequence of an
> optional property  being possible.

OK.

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

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

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

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

> > In another language binding that doesn’t support object indexing like
> > this, the operations would correspond to methods, e.g. in Java the
> > interface would be:
> >
> >  interface FileMetadata {
> >    Object getProperty(String propertyName);
> >    void setProperty(String propertyName, Object value);
> >  }
> 
> I understand that you are concerned with the Java language binding
> here since it doesn't support non-final properties in Java interfaces.
> However such a Map-like interface would perfectly map to Java's
> Hashtable class for instance, given that some extended interface
> attribute like [Enumerable] would exist.

OK I can see that the above Java interface wouldn’t let you enumerate
the supported named properties.

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

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

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

Received on Friday, 3 July 2009 01:00:46 UTC