Henrik Gedenryd <h.gedenryd at open.ac.uk> wrote:
> goran.hultgren at bluefish.se wrote:
> > without any neighbor modules. So ok, I need to do it explicitly, I ran
> > the "self deepDeclareExternalRefs." from the explorer-thingy and then
> > BAM, it added two neighbors:
> > 
> > #(Squeak Language Core)*
> > #(Squeak Language Collections)*)
> > 
> > I am not sure why it didn't go all the way down to Streams... Even
> > adding a reference to ReadStream didn't make it go there. It actually
> > seems that these two modules are always neighbors - even with an empty
> > method!
> 
> The modules Language Core and Language Collections import all their
> submodules, including ReadStream.

Duh. So obvious.

This is actually kind of cool and I hadn't realized it. As you explain
further this means that we can "import" modules using different
granularity depending on what we mean. That's nice.

[SNIP] 
> An auto-declarer can never discover that this is the "correct" higher-level
> logic behind your code, because sometimes you may want to import exactly two
> of the B3D submodules instead of all of B3D or whatever.

Agreed.
 
> > 1. Imports are made on module level. We already have that - the neighbor
> > modules. I think.
> > 2. If you type a direct reference in the code it would generate an
> > automatic neighbor module reference on compile. It would of course barf
> > if that module is not loaded (it doesn't have to be active, right?).
> > 3. If you type a non direct reference like "EllipseMorph" then I would
> > like it to:
> > 1. If there is already ONE and ONLY ONE neighbor module exporting
> > EllipseMorph then do nothing. All is fine.
> > 2. If there are two or more neighbor modules exporting EllipseMorph
> > then barf and ask user to make a direct reference using whatever
> > syntactic means there are for that. :-)
> > 3. If there are no neighbor modules exporting EllipseMorph, find it
> > among all loaded modules and if there is ONLY ONE - add that module as a
> > neighbor. Ask user for confirmation. This could be a Preference.
> > 4. If there are more than one loaded module exporting EllipseMorph, ask
> > which one should be added as a neighbor.
> 
> This sounds like a very good solution.

Thanks. :-) But we should perhaps refine it by adding options for
aliases as you describe them.

> Now, as you noted, there still is the odd case when you need to specify in
> your code exaclty what module to pick a name from, e.g. where there is a
> name conflict (perhaps Component is more likely to have a conflict than
> EllipseMorph though!)
> 
> Like David S. noted (and Les did last fall), giving the full path inside
> your code is brittle. So I fully agree,
> 
> ellipse := Squeak Morphic Core Basic EllipseMorph new.
> 
> is not a great idea. That is why you can use aliases for external modules,

Aahhh. That's nice. And then we also have the "module parameters" (which
I would like to call "parameter modules" but that is another story) to
help us even further.

regards, Göran