- From: Cameron McCormack <cam@mcc.id.au>
- Date: Wed, 14 Jan 2009 10:30:06 +1100
Ian Hickson:
> > > For DOMStringMap, my intention was to not provide methods at all, and
> > > only provide the JS-native mechanisms.
Maciej Stachowiak:
> > A bold choice, but I would not recommend it as the sole available
> > mechanism.
Ian Hickson:
> See above for UndoManager, but for DOMStringMap I don't want to add any
> other mechanisms, because they introduce name clashes. Right now the IDL
> for DOMStringMap is:
>
> [NameCreator, NameDeleter, NameGetter, NameSetter]
> interface DOMStringMap {};
>
> It basically emulates a JS Object. It's intended only for JS. I don't see
> why this is a bad idea.
At the moment, the interface is useful only for JS (and other languages
that support this kind of indexing). For other languages, a
DOMStringMap object would appear to be a completely opaque object
without any means of interacting with it. Given that this is basically
meant to be a shorthand for getting/setting attributes with particular
names, I would be happy with it not existing in other language bindings.
Web IDL doesn?t have a mechanism to state that an interface member or a
definition should only be included if the target language binding is a
particular one, though.
An alternative would be to put operations on the interface to act as the
getters/setters/etc., and use the [NoIndexingOperations] extended
attribute to indicate that these operations won?t correspond to
properties in language bindings such as ECMAScript. That would then at
least make the interface useful for other languages.
--
Cameron McCormack ? http://mcc.id.au/
Received on Tuesday, 13 January 2009 15:30:06 UTC