Henrik Gedenryd wrote:

> goran.hultgren at bluefish.se wrote:
> 
>>hopefully Squeak will "auto
>>import" a module during compilation - at least if there is only one
>>module active that does define that name. Henrik?
> 
> Right. This is what deepDeclareExternalRefs does. But automatic declaration
> is not really an option, your module dependencies really describe the
> "organizational logic" of your code, which isn't evident from the names you
> use.
> 
> For example, if your module uses Balloon3D heavily, the auto-declarer will
> add, say, dependencies on five or more submodules of Balloon3D instead of a
> single one to the Balloon3D module, which would be the logically right thing
> to do. (Balloon3D then ought to import its submodules so you only need to
> declare a single dependency on that module.)
> 
> 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.


Auto-declaration (auto-import) of required modules would still be nice 
to have as an option, if not as the default.  (Actually I don't think it 
would be *that* bad as the default, either.)

I assume that things would still work if you completely relied on 
auto-declaration?  The declarations would just be sloppier, as you 
say... you might have a group of submodules declared when you logically 
should just declare a dependency on the whole module.

Auto-declaration might be workable if you had a module browsing tool 
with a good UI, which made it obvious when you had this sort of 
sloppiness in your declarations, and made it easy to clean things up.


> 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,
> e.g. you'd declare that your module depends on #(Squeak Morphic), and that
> this module should have the alias Morphic inside your module.
> 
> so in the dependencies (the "interface" of the module):
> 
>     ... externalModule: #(Squeak Morphic) alias: #Morphic ...
> 
> and in your code,
> 
>     morph _ Morphic Component new
> 
> to distinguish it from the Component class in the super-meta-reflective
> programming code you also depend on:
> 
>     ... externalModule: #(Project FancyMetaProgramming) alias: #MetaSystem
> ...
> 
>     model _ MetaSystem Component new
> 
> I think this is acceptable, even probably preferrable to other solutions
> IMHO.


I agree that this sounds better than using full paths.  If this is done, 
then the debate about exactly how to specify full paths becomes less 
important.


> On the same note, using prefixing, i.e. always using Morphic Component
> instead of just Component, probably leads to less brittle code, since you
> are always explicit and clear about where you are taking a name from. Just
> "blindly" using imported names from all over can lead to really confusing
> bugs.

Hmm, this is a close call... I'd say comparing prefixing (with aliasing) 
versus no prefixing (blindly using imported names), neither would be all 
that brittle.  Using no prefixing would require that the tools do more 
work, e.g. to notify you when you've imported/declared a new module 
which happens to import a duplicate name which your code references, 
which you now must make explicit.  (Making the appropriate references 
explicit could then be done automatically at the press of a button, as 
Stephen suggested.)

I guess that's the main difference between the two approaches:

You can either do prefixing, which requires that you set up aliases and 
always include a module prefix before every classname (bad), but then 
you don't have to worry about having a duplicates problem when you 
import/declare new modules (good).

Or, you can blindly use imported names, and not have to worry about any 
aliases or adding prefixes before classnames (good), but you might have 
a problem when importing a new module (bad).  (But then, if this problem 
  is handled relatively automatically when it occurs, is it really that 
much of a problem?  I can't think of any "confusing bugs" that might 
happen that wouldn't be solved by making the appropriate references 
explicit at the right time, although I may be missing something.)

Hm, I admit that prefixing could be helpful for readability in certain 
cases, such as with something like "Component", which might be too vague 
on its own, and might appear in a few well-known modules... in that case 
if you use "Morphic Component" you're identifying it as, well, the 
Morphic Component, not some other Component.


> If people don't want to have to declare aliases all the time, then the name
> of the last module in the path could be allowed as a default, ie. #(Squeak
> Morphic) would allow Morphic as an alias by default, but perhaps that is not
> worth the potential confusion.


Yeah, that might be a bit tricky.


- Doug Way
   dway at riskmetrics.com