2010/1/18 Kam Kasravi <[email protected]>: > 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 <[email protected]> > To: Kam Kasravi <[email protected]> > Cc: Andy Chu <[email protected]>; kkasravi <[email protected]>; Brendan Eich > <[email protected]>; es-discuss <[email protected]> > 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 <[email protected]>: >> 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 <[email protected]> >> To: Kam Kasravi <[email protected]> >> Cc: Brendan Eich <[email protected]>; kkasravi <[email protected]>; >> es-discuss <[email protected]> >> 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 <[email protected]> >> 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 >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
