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
> 
>