Doug Way <dway at riskmetrics.com> wrote:> 
> 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. :-) )

The choice of automatic altering is fine, just put a popup in there
perhaps based on some Preference.
One note there though: Stephen was talking about allowing to have
implict references in the code EVEN THOUGH there are multiple choices
(more than one neighbor module exporting the name). Thus such a
reference would depend on the ordering of the neighbor modules (which
btw Henrik has noted in the class comment of Module).

But it sounded as Stephen wa talking about having "the old" references
still point to the "old" name but the new ones (after having added the
extra neighbor) point to the new name. Uahh! That sounds SCARY to me.
How would I know what it points at by reading the code? Perhaps I
misunderstood.

My view is that if people insist on still having implicit references
EVEN THOUGH there are multiple neighbors exporting the name - it would
rely on the ordering of the neighbors for lookup (as Henrik noted). But
I would actually propose to have a Preference to disallow such implicit
references (and in those cases enforce explicit references) - and the
default setting for that Preference would be True.

> Göran also refers to "neighbor" modules, which sounds vaguely familiar from long-ago discussions on this list.

Thanks for bothering with my dots! My name sounds so much better then!
:-) :-) (ö like in "k(E)rnel" and G like in "(Y)ikes")

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

It is actually explained in the class comment of Module. Don't you have
a 3.3alpha image up and running?! :-)
In short it says:

"All "neighbor modules"--external modules, submodules, module
parameters, delta modules--are held in an OrderedCollection to strictly
define the order of lookup for names defined outside this module."

...and that is actually also the name of the instance variable. Henrik
had probably a hard time to come up with a name for this because a
Module sees exported names for both external modules (what you would
call typical "imports" or "prefrequisites"), submodules, module
parameters and deltamodules.

So the neighbors are simply ALL other Modules that the Module "sees". We
might come up with a better name but the name "prerequisite" does not
seem to cover more than perhaps the external modules.

My advice: Let's stick with neighbors for now. We can always change it
later WHEN WE ALL KNOW MORE. :-) :-)

PS. Finally moved over to a FREE Dekstop! So nice. Running Debian Woody,
2.4.17, ALSA (Phew - that was a bit tricky) and KDE (for starters).
Finally I can begin to build those VMs! :-) Lex, if you are reading this
- what do I need to do for sound? Nas or OSS? I saw that the .debs had
two VMs for that. DS