These ideas and Göran's sounds good to me... they're similar to what I had in mind.

Stephen Pair wrote:
> ...
>  - upon importing, we could also have the option to alter the source of
> all methods that have these ambiguous implicit references (this is
> probably the option that I would always use)

Would this be manual or automatic altering?  Manual altering would probably be fine for starters.  But it would be neat to have an option to automatically change the implicit references to explicit references (to your choice of one of the two conflicting imported modules).  In many cases you might know which of the two imported modules you'd want to use in the case of conflicts, without looking at each reference individually.  (Granted, this is not a high-priority near-term thing to worry about. :-) )

Göran also refers to "neighbor" modules, which sounds vaguely familiar from long-ago discussions on this list.  But I didn't see any references to neighbor modules in the Modules info on the Swiki.  (Perhaps a brief writeup on the swiki would be helpful.)

(I may be oversimplifying, but it sounds like neighbor modules could be considered the required (imported, prerequisite, etc.) modules for a particular module?  If so, I wonder if a term like "prerequisite" might more accurately describe this one-way relationship.  The term "neighbor" implies a two-way sibling-like relationship to me.)

- Doug Way
  dway at riskmetrics.com


Stephen Pair wrote:
> 
> I like these ideas.  It would be very nice to be able to write code and
> have very explicit knowledge and control over what other modules I'm
> basing my work on.
> 
> Regarding the issue of importing a new module that has a duplicate
> export of a symbol that's already being used...maybe the solution to
> this problem is to enhance what the compiler is producing.  Rather than
> compile in references directly to an association, maybe we should
> compile in a reference to something a little more sophisticated...if we
> change the VM such that the #value method is actually sent (rather than
> make an assumption about having an association), this should be an easy
> thing to achieve (and it's arguably the right thing to do regardless).
> 
> Once this is in place there are lot's of options regarding how to handle
> such a situation:
> 
>  - when adding the imported module, we could warn about existing
> conflicting implicit references that you may wish to make explicit
> (although with the changes above, making such a change would be
> optional)
>  - upon importing, we could also have the option to alter the source of
> all methods that have these ambiguous implicit references (this is
> probably the option that I would always use)
>  - if the user decided not to make references explicit, we could have an
> option that warned the user via syntax highlighting when they view the
> method in the browser (a red block around the implicit reference)...this
> would be controlled by a preference setting of course
>  - for the same situation as the previous point, we could also warn via
> a popup message (though this is more intrusive than I would like)
> 
> On another note, regarding the upper case convention, what happens for
> lowercase modules names?  Like "People svp"?  Would we need to make the
> people modules upppercase?  Like "People Svp" or "People SVP"?
> 
> - Stephen
> 
> Goran wrote:
> > Ok, apart from how we syntactically write direct references
> > in the module system I would envision this:
> >
> > 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.
> >
> > The problem I see with all this is that we can not guarantee
> > that the non direct references are ok. If I add a neighbor
> > module which also exports EllipseMorph - which one does the
> > old method reference now? That could on the other hand be
> > checked by the system - when we add neighbors we could
> > crosscheck the exported names and if there are overlaps we
> > could check if those names are referenced in the methods of
> > the class and if they are then we need to ask the user to
> > either abort adding the neighbor or change the references
> > into direct references.
> >
> > Phew.
> >
> > Well, whatever, perhaps I am "out bicycling" as we say in Sweden. :-)
> >
> > regards, Göran
> >
> > PS. One "value" I like is to be able to just type
> > EllipseMorph and that would be ok. I want Squeak to
> > "autoimport" semiintelligently and perhaps sprinkle it with a
> > few confirmations based on Preferences. DS
> >
> >