On Sun, Nov 3, 2013 at 12:34 PM, David Herman <dherman at mozilla.com> wrote:
> IOW expose the first-class "reference type" of ECMA-262 via a standard library? Just say no! :)

I was thinking that if they were used anyway by the module system,
formalizing them might help, the "provide the primitives" sort of API
design. I am sure that kind of consideration is probably quite a bit
of work though (sounds like scary too from your response), so sorry
for the distraction.

> BTW, this whole module-function rigamarole only exists for AMD compatibility, so it's only important for it to demonstrate interoperability. For normal ES6 use cases there's just no need to use it.

I was not asking about it related to AMD compatibility. AMD's cycle
support is not that strong, so this capability would not be used
specifically for AMD conversions, as that concept is not possible now
with AMD.

This came out of wanting some other way to inline multiple ES-type of
modules in a file, without needing to rely on the JS-strings-in-JS
that were mentioned in the previously mentioned thread. The thought of
being able to use a function instead was appealing, but wanted to be
sure a similar cycle support to ES modules could work in that format.
Not an exact match for true import/export syntax, but may be good
enough for single, default export type of modules.

I will try to wait until the later November design artifacts are done
before asking more questions.

James

On Sun, Nov 3, 2013 at 12:34 PM, David Herman <dherman at mozilla.com> wrote:
> IOW expose the first-class "reference type" of ECMA-262 via a standard library? Just say no! :)

I was thinking that if they were used anyway by the module system,
formalizing them might help, the "provide the primitives" sort of API
design. I am sure that kind of consideration is probably quite a bit
of work though (sounds like scary too from your response), so sorry
for the distraction.

> BTW, this whole module-function rigamarole only exists for AMD compatibility, so it's only important for it to demonstrate interoperability. For normal ES6 use cases there's just no need to use it.

I was not asking about it related to AMD compatibility. AMD's cycle
support is not that strong, so this capability would not be used
specifically for AMD conversions, as that concept is not possible now
with AMD.

This came out of wanting some other way to inline multiple ES-type of
modules in a file, without needing to rely on the JS-strings-in-JS
that were mentioned in the previously mentioned thread. The thought of
being able to use a function instead was appealing, but wanted to be
sure a similar cycle support to ES modules could work in that format.
Not an exact match for true import/export syntax, but may be good
enough for single, default export type of modules.

I will try to wait until the later November design artifacts are done
before asking more questions.