Module system strawpersons

Mike Samuel mikesamuel at gmail.com
Mon Jan 18 14:44:48 PST 2010


2010/1/18 Kam Kasravi <kamkasravi at yahoo.com>:
> Hi Mike
>
> The former but not in the way you've described. Rather
>
> module A:
> this.getB= function() {
>   return new (import 'B')();
> }
>
> module B:
> this.getA = function() {
>   return new (import 'A')();
> }
>
> If modules eagerly resolve imports then the above circular dependency would
> be a problem.
> If modules lazily resolve imports then the above circular dependency would
> be ok.
> If catch-alls were used then proxy's would be used and the circular
> dependency would be ok.
> Current js has many examples of circular dependencies which are resolved by
> lazy evaluation.

Ok.
Ihab's proposal allows eager fetching, and mandates lazy
instantiation, so the above example is not a problem with Ihab's
proposal.


>
> Kam
>
> ________________________________
> From: Mike Samuel <mikesamuel at gmail.com>
> To: Kam Kasravi <kamkasravi at yahoo.com>
> Cc: Andy Chu <andy at chubot.org>; kkasravi <kkasravi at me.com>; Brendan Eich
> <brendan at mozilla.com>; es-discuss <es-discuss at mozilla.org>
> Sent: Mon, January 18, 2010 1:50:15 PM
> Subject: Re: Module system strawpersons
>
> I don't quite understand what is meant by circular dependencies in this
> context.
> Are you talking about the graph of imports, or the graph of module
> instances?
>
> If the former, how is it a problem?
>
> If the latter, how could it occur without explicit user intent : a
> module explicitly passing itself to a dependency?
>
> E.g. in the former
>   // fib.js
>   var self = (import "fib.js");
>   if (n < 2) { return n; }
>   return self({ n: n - 2 }) + self({ n : n - 1 });
> a module imports itself, and recursively invokes separate instances
> which is stupid but does not result in a module being observed in a
> partially initialized state.
>
> In the latter:
>     // foo.js
>     var otherModuleMaker = (import "bar.js")({ baz: this });
> module foo is explicitly allowing otherModuleMaker to observe it in an
> uninitialized state.
>
> 2010/1/18 Kam Kasravi <kamkasravi at yahoo.com>:
>> Andy
>>
>> yes I was referring to the circular dependency issue.
>> Catch-alls would be useful for this, though it would be nice if
>> they were automated, eg returning a proxy until the module was used.
>> Doing it manually by developer would be too difficult.
>> I realize modules are intended to just satisfy a function body and
>> can be initialized as objects or called as functions, but since they
>> have strong container semantics I wonder if they should
>> have more than just an 'id' especially if they provide a gateway
>> to what else is in the directory as in commonjs.
>>
>> Kam
>>
>> ________________________________
>> From: Andy Chu <andy at chubot.org>
>> To: Kam Kasravi <kamkasravi at yahoo.com>
>> Cc: Brendan Eich <brendan at mozilla.com>; kkasravi <kkasravi at me.com>;
>> es-discuss <es-discuss at mozilla.org>
>> Sent: Mon, January 18, 2010 12:40:35 PM
>> Subject: Re: Module system strawpersons
>>
>> On Mon, Jan 18, 2010 at 10:29 AM, Kam Kasravi <kamkasravi at yahoo.com>
>> wrote:
>>> Yes, that looks right, I also remember a reference to the 'dot' notation
>>> where namespace
>>> access would be arbitrated implicitly by objects representing the '.' It
>>> may
>>> have been in
>>> one of Lars Hansen papers on gradual typing. In any case there was some
>>> good
>>> discussion
>>> on meta-level objects and controlling capabilities or access.
>>>
>>> Was there any discussion in the past about parameterized modules or
>>> units where recursively nested modules/units were brought up? If two
>>> modules
>>> refer to each other
>>> and all imports are resolved eagerly then I think this would be a problem
>>> where use cases would
>>> abound.
>>
>> What are you referring to here?  I think you are hinting at the
>> problem of circular dependencies using "import" semantics like Python
>> and CommonJS.  Right now if you have mutually recursive modules, you
>> get partially initialized modules, because the "program counter" just
>> follows every require().  The CommonJS spec specifically allows the
>> partially initialized modules I think.
>>
>> Personally I try to break up circular dependencies, but this behavior
>> is not very friendly, so I think it would be better if Harmony
>> supported circular dependencies in a more "correct" way.  So this is
>> an advantage of the "makers" style semantics (separating module
>> definition and configuration).
>>
>> The Newspeak paper talks explicitly about this:
>>
>> http://scholar.google.com/scholar?hl=en&source=hp&q=objects%20as%20modules%20in%20newspeak&um=1&ie=UTF-8&sa=N&tab=ws
>>
>> If you are initializing modules in topological order, and there is a
>> circular dependency between A and B, he says to just make a dummy
>> proxy object for B to pass into A, initialize A, and then initialize
>> B.
>>
>> That also reminds me that a good use case for catchalls is making
>> module-like objects.  I haven't seen any discussions of the 2 together
>> but it's definitely worth thinking about how they interact.
>>
>> Andy
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>


More information about the es-discuss mailing list