Re: [WebIDL] "module" in ECMAScript

Hi Marcin.

Marcin Hanclik:
> In BONDI WebIDL we implicitly assumed that "module" definition is
> mapped to the interface naming. Thus bondi.filesystem.* is available
> without explicit creation of the "filesystem" property of the
> "bondi" object. This implicit creation of property may result from
> the definition of submodules, as in [3]. However, this is just an
> incorrect interpretation of the WebIDL for ECMAScript that resembles
> bindings of WebIDL in Java [7]. The WebIDL "module" has no meaning in
> ECMAScript [8]:
>
> "In the Java language binding, the name of the Java package is derived
> by taking the prefixed name and replacing occurrences of "::" with "."
> (see section 5.3). The ECMAScript language binding does not have a
> namespacing mechanism, and thus does not use a module's prefixed name."
> 
> [9] says that:
> 
> "For every interface that is not declared with the [NoInterfaceObject]
> extended attribute, a corresponding property MUST exist on the
> ECMAScript global object whose name is the identifier of the
> interface. The value of this property is an object called the
> interface object, which provides access to the constants and
> operations defined on the interface."

Indeed.

> In BONDI, however, we do not want the interfaces to be available under
> the global object. This is visible also from the sample code for
> constant usage [10]:
>
>   try {
>     // gets current night mode
>     var night_mode = camera.getFeatureValue(bondi.camera.Camera.NIGHT_MODE);
>     // Switch on nightmode
>     camera.setFeatureValue(bondi.camera.Camera.NIGHT_MODE, true);
>   }
>   catch(e) {
>     alert(e);
>   }

OK.

> …
> Subclassing in Gears may resemble "module in module" definitions in
> WebIDL, but frankly speaking I did not find anywhere an example of
> "module in module" binding in ECMAScript.

Right, while it’s common in some Javascript toolkits, like dojo, this
naming scheme isn’t used by standard DOM interfaces.

> In HTML5 the interfaces are available under the global object and
> interfaces are available as properties to create hierarchical
> structures. E.g. window.locationbar.visible [11] is possible, because
> locationbar is an attribute of the Window interface [12].
> 
> In BONDI we are now planning to clarify that the module within module
> definition has the semantics of the submodule being an attribute for
> the enclosing module. Naming structure is still under discussion.
>
> E.g. we could have
> module bondi {
>         module pim {
>                 module task {
>                 ...
>                 };
>         };
> };
> to be equal to:
> 
> interface TASK {
>         ...
> };
> 
> interface PIM {
>         attribute TASK task;
>         ...
> };
> 
> interface bondi {
>         attribute PIM pim;
>         ...
> };
> ...

Right, I think at the moment you would need to write such interfaces to
achieve the kind of namespacing that you want.  This is cumbersome.

> but with the above we still may have problems with the constants, I
> think.

What is the issue with constants?

> Question:
> a) Is any further standardization planned for refining of the
> semantics of the "module" within ECMAScript?

I’m open to adding a feature that would map modules to ECMAScript
objects as above.  I don’t think this should be the default, since at
the moment it’s definitely the norm to place all interface objects on
the global object.

> We could foresee here something like automatic generation of the
> property/attribute for submodules or similar text.

I think it would be better just to state how modules map to particular
ECMAScript properties and values.

> I would be grateful for any clarification or pointing to some archives
> if the above topics has been discussed already in the past.

I don’t think it has been discussed.  (Some specification authors have
been reluctant to use the module construct in the first place, given
that the behaviour we have at the moment is that everything ends up on
the global object in ECMAScript.)


Here is a proposal then, by example.  The following IDL:

  [ESNamespace]
  module bondi {
    module pim {
      interface Blah { };
    };
  };

  module dom {
    interface Node { };
  };

  module gfx {

    [ESNamespace]
    module geom {
      interface Point { };
    };
  };

  [ESNamespace, Prefix=com::example]
  module fs {
    interface File { };
  };

would cause the following properties to exist:

  window.bondi – “namespace object” for ::bondi
  window.bondi.pim – namespace object for ::bonid::pim
  window.bondi.pim.Blah – interface object for ::bondi::pim::Blah
  window.Node – interface object for ::dom::Node
  window.geom – namespace object for ::gfx::geom
  window.geom.Point – interface object for ::gfx::geom::Point
  window.com – implied namespace object
  window.com.example – implied namespace object
  window.com.example.fs – namespace object for ::fs
  window.com.example.fs.File – interface object for ::fs::File

Properties whose values are namespace objects would be { DontDelete,
DontEnum } for consistency with properties for interface objects.

The [ESNamespace] name is a strawman.  Please suggest a nicer name if
you can think of one.

With the above, there’d be no way of “turning off” mapping of a module
to a namespace object if an ancestor module had [ESNamespace] on it.

I’m not sure about the usefulness of the [Prefix] bit, but I’m just
copying the same behaviour that exists in the Java binding.

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

Received on Monday, 1 June 2009 02:21:12 UTC