On 20-12-2013, at 1:56 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:

> If both Griffle and Plonk provide Feep, I expect to get Plonk's Feep, not Griffle's, or worse, a Feep that was defined even before Griffle or Plonk. So to me the order makes sense.
> 
> Importing is very different from a search path, which indeed would be resolved the other way around.

I *think* I disagree. Let’s see if I can write it down well enough to make sense even to me…

I think that ‘my’ code is the innermost environment,  and anything inner over-rides anything ‘outer’. So, Smalltalk is the base, outermost world; all the defaults, if you like to think of it that way. If I write code in an inner environment (which ought to be the norm for writing any sort of app; obviously with my history I’d probably be editing base code most of the time…) then it trumps the defaults. If I import other packaged environments then they go under/inside Smalltalk and above/outside my environment.

When anything is imported/linked, some form of notification of any clashes will be required. Rather than anything direct to the UI we should raise exceptions; that way a UI based importer can catch any problems and present them one at at a time or bundled in a nice browser (think of the little issue browser you get when loading an Excel file into Numbers). A batch process can catch the exceptions and either handle them according to some rules or simply fail and back out. If you’ve developed code with an import in mind then the needed rules ought to have been worked out before any deployment and should be codified in your init code.

If we import something part way through development, we probably have to handle both the import over-riding stuff from the next-outermost environment as well as producing complaints from your development code that is now over-riding (maybe) stuff in the import. Or, maybe, this shouldn’t be allowed; instead you decide another imported package is needed and you have to 
a) import it into the next-outer environment
b) effectively export your working environment and import it into a new environment under the new package. Obviously this ought to be automagicable for convenience. 

Clearly a lot of packages are effectively siblings rather than parent/child but I suspect that trying to have two different forms of import would be confusing and troublesome. If there are no clashes it surely shouldn’t make any difference which order they get imported?


tim
PS the random sigline may well apply better than normally in this case.
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful random insult:- On permanent leave of absence from his senses.