[Modules] Upper case message names for accessing modules

Stephen Pair spair at advantive.com
Wed Feb 27 14:28:16 UTC 2002


Is it settled then?  Let's at least allow aliases for external modules
for now and change the module def file to accomodate that.  Allowing
module substitutions and config specs can come later.  I'd prefer it if
aliases were required when importing a module (then people would be more
likely to use the alias for explicit references rather than the full
module path).  I think my personal coding practice would be to use
explicit references through aliases in any reference to an external
name...it just seems like the best thing to do and "Morphic Component"
is not ugly at all.

So, I'm studying the code and I see that ModuleReference has a method
called #alias.  Which is exactly where I would have put a method to look
up the alias for a neighbor module in the definedNames.  What is the
indentended use for this alias?

- Stephen

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Doug Way
> Sent: Wednesday, February 27, 2002 12:57 AM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: [Modules] Upper case message names for accessing modules
> 
> 
> 
> 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
> 
> 
> 




More information about the Squeak-dev mailing list