Look Ma, no "this" (was: ECMAScript Harmony)

ihab.awad at gmail.com ihab.awad at gmail.com
Mon Aug 25 17:46:49 PDT 2008


On Mon, Aug 25, 2008 at 5:23 PM, Brendan Eich <brendan at mozilla.org> wrote:
> On Aug 25, 2008, at 4:57 PM, Peter Michaux wrote:
>> I think the ability to have two modules in one file means modules will
>> need to name themselves. That is they will need to be declared with a
>> name like
>>
>> module foo {
>>   // ...
>> }
>>
>> or
>>
>> var foo = module {
>>   // ...
>> };
>>
>> The importer could rename things but somehow the importer will have to
>> use the name "foo" to at least start importing.
>
> I will let Ibad^H^H^H^HIhab jump in here ;-).

Hey, I *liked* that name.... };->

If "module" === "compilation unit" (a position I advocate since,
within a compilation unit, there are bunches of other ways to divvy up
lexical scopes), then naming what is imported is the responsibility of
the hitherto-unspecified "fetchModule()" black hole we talked about
earlier. So the module construct (if any) need not, *on these
grounds*, contain any name.

When several modules are put into one compilation unit (essentially
=== "file") for optimization, the question is whether this needs to be
done using "cat" or via some other more sophisticated process. For
example, a module can always be wrapped in a function. Hence the
import --

  var z = importModule(fetchModule('foo.bar.baz'), {x: 3, y: 4});

can be rewritten by the optimization framework into --

  var $foo_bar_baz$ = function(x, y) {
    // The code of "foo.bar.baz" here
  };

  var z = $foo_bar_baz$(3, 4);

This is only a simple example of one way to do it.

Under these circumstances, minifying could be achieved if the symbol
export/import mechanism at the module boundaries is idiomatic enough
to be statically discernible.

>> By cycles you mean module A using module B which uses module A? Late
>> "linking" would required to allow cycles, correct?
>
> Yes. Any early linking would mean no cycles allowed, leaving us with
> second-class modules of the PLT Scheme kind ...

Perhaps I should clarify what I was thinking about here, and see what
everyone thinks. Let's consider *instances* of modules. I'll talk
about the 0th instance of module A (say) as A[0]. So we have --

1. Cycle of module code; different instances --

  (someone) --instantiates--> A[0] --instantiates--> B[0] --instantiates--> A[1]

where A[0] and A[1] are isolated instances with no built-in communication paths.

2. Cycle of module instances --

  (someone) --instantiates--> A[0] --instantiates--> B[0] --reuses--> A[0]

In case #2, this can be done by A[0] passing down, during the
instantiation of B[0], some reference to (parts of) itself --
typically, some symbols that B[0] needs.

How does this serve the needs at hand?

Ihab

-- 
Ihab A.B. Awad, Palo Alto, CA


More information about the Es-discuss mailing list