RE: [WebIDL] "module" in ECMAScript

Hi Cameron,

A correction / question to what I stated below:

>>>>  window.bondi – “namespace object” for ::bondi
>>In BONDI we did not foresee that.
>>We would like bondi to be the root.
Which of the following do you foresee to exist:
1. window.bondi.* only
2. bondi.* only
3. both from the above?

Thanks.

Kind regards,
Marcin


Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Marcin Hanclik
Sent: Tuesday, June 09, 2009 5:18 PM
To: Cameron McCormack; public-webapps
Subject: RE: [WebIDL] "module" in ECMAScript

Hi Cameron,

I am sorry for responding that late, but my mail client wrongly classified your message and I realized of its existence right now :)

>>What is the issue with constants?
We would like to have this constant
bondi.camera.Camera.NIGHT_MODE
to be only accessible as above.
Camera and Camera.NIGHT_MODE should be undefined.

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

>>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
In BONDI we did not foresee that.
We would like bondi to be the root.

>>  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.
It seems ok as it is.

>>
>>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.
In BONDI we would like to add new submodules to the bondi module.
So probably [Prefix=bondi] would help us to extend this namespace.

>>I’m open to adding a feature that would map modules to ECMAScript
>>objects as above.
OK.

>>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.
I think it would be good to know whether the changes you want to make will be persistent, since e.g. BONDI spec would like to reference WebIDL spec.

Thanks.

Kind regards,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Cameron McCormack
Sent: Monday, June 01, 2009 4:20 AM
To: public-webapps
Subject: 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/



________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Received on Wednesday, 10 June 2009 13:24:51 UTC