Peter Michaux wrote:
> I'm a bit late to this module party...
>
> On Tue, Aug 19, 2008 at 1:00 AM, Ingvar von Schoultz
> <[EMAIL PROTECTED]> wrote:
>
>> From the descriptions it looks like this could instead use
>> a syntax based on destructuring assignment, if es-harmony
>> will have destructuring:
>>
>> var {toggle: t, set: s} = import
>> ( fetchModule ('http://foo.com/someModule.js'),
>
> Are "module" and "file" synonymous? See
>
> http://dev.helma.org/wiki/Modules+and+Scopes+in+Helma+NG/
>
> What do the contents of the http://foo.com/someModule.js file look like?
>
> fetchModule would need to work with the local file system for server-side
> work.
>
> What exactly does fetchModule return? Some kind of first-class Module
> class instance or is it returning the object which is being
> destructured?
Some of your questions are answered in the post by Ihab that I was
replying to:
https://mail.mozilla.org/pipermail/es-discuss/2008-August/006915.html
In short, the name fetchModule() is just a placeholder to sidestep
the whole issue of files, downloads etc. That's part of the host
environment, and won't be defined in the language standard.
The details of the exact division of tasks between host environment
and language [and thus between fetchModule() and import()] were not
discussed at all, as I recall.
>> {document: doc, background: bg}
>
> What does this argument to import do?
It's stuff that the module needs (requires), packed into an object.
But my only role in the discussion was to propose a syntax. Ihab
discussed possible semantics and needs of modules, and showed these
semantics with a possible import syntax. I proposed that reuse of
existing syntax seemed to be enough, based on the needs and semantics
that had been discussed.
<ImportedStuff> = import (<Module>, <NeededStuff>);
The argument that you ask about is the <NeededStuff> argument.
--
Ingvar von Schoultz
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss