[Bug 12248] Make objects first-class API citizens

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12248

--- Comment #32 from Allen Wirfs-Brock <allen@wirfs-brock.com> 2011-03-16 17:37:11 UTC ---
(In reply to comment #31)
> 
> I just mean that at the abstract IDL level, there is no concept of whether an
> attribute was specified or not -- all attributes of a [Callback] interface
> implemented by JS have a value, just by virtue of the wording currently in
> http://dev.w3.org/2006/webapi/WebIDL/#native-objects.

"Some interfaces can be implemented in script by an ECMAScript native object.
Only interfaces with the following characteristics can have native object
implementations: "

This continues to be a problematic restriction as we eventually intend to
implement all DOM interfaces using ECMAScript native objects.

> 
> So Web IDL, as part of fixing this bug, needs to map that
> JS-property-present-or-not to something at the IDL level, so that
> specifications can reference it in a language independent manner.

It would presumably be easy enough to add some sort of "optional" modifier to
IDL attributes and ECMAScript would have no trouble dealing with this concept.
I'd be more concerned about the mapping to more static languages that expect
all objects/structures to have a fixed set of fields.

One way to deal with this would be to specify all such option parameter objects
using a single common "OptionBag" interface. That interface would represent a
dynamic set of key/value pairs and the interface would  expose hasOption and
getOptionValue methods. Any method that uses an OptionBag parameter would
specify (perhaps tabularly) the actual option keys and values that it accepted.
 This could then be mapped into any language.  For ECMAScript, the bind could
just be to an native object with hasOption/getOptionValue mapping to
hasOwnProperty and regular property access.

Alternatively, you might want to look at the primary reason for the existence
of these option objects. They're there to support an ECMAScript idiom for
passing optional keyword arguments.  Some languages have direct support for
optional keyword arguments.  Someone doing a WebIDL language binding for such a
language would probably want to directly use that language mechanism rather
than passing an options object.  However, specifying a method signature with a
with an explicit parameter object typed with some interface (even OptionBag)
would seem to preclude using such native optional argument techniques.

What you could do instead, is simply permit WebIDL method signatures to have an
arbitrary number of optional keyword arguments. In an interface definition
these would be all be specified as discrete arguments.  They would not be
specified as being grouped together into an object.  The specification for each
method would also define its behavior simply in terms of the presence or
absence of various arguments. It also would not be expressed in terms of an
options object.

The mapping of optional keyword arguments into in a single options objects
would only be discussed as part of the ECMAScript language binding or the
bindings of other languages that wanted to use that technique.  The language
bindings for other languages that directly support optional keyword arguments
would map such arguments using the native language facility.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Wednesday, 16 March 2011 17:37:20 UTC