Environments: Import order

One thing I just noticed is that the #import... methods on Environment
seem to chain the imports in order they are added.  This means the
last-added is first-searched when resolving names.

Seems like first import should be first-searched...?

On 20 December 2013 20:40, Chris Muller <[hidden email]> wrote:
> One thing I just noticed is that the #import... methods on Environment
> seem to chain the imports in order they are added.  This means the
> last-added is first-searched when resolving names.
>
> Seems like first import should be first-searched...?

I think the behaviour's the correct one: adding imports is like
wrapping a present in layers of paper: the last added layer/import is
the outermost layer.

frank

Well, it's backward from how name-resolutions works in other languages
like Java, isn't it?

On Fri, Dec 20, 2013 at 3:03 PM, Frank Shearar <[hidden email]> wrote:

Plus, the way the API is used

myEnvironment
    import: #Griffle ;
    import: #Plonk

looks more like a chain-of-responsibility list..  Not that Plonk
"wraps" Griffle..

On Fri, Dec 20, 2013 at 3:35 PM, Chris Muller <[hidden email]> 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.

- Bert -

On 20.12.2013, at 22:49, Chris Muller <[hidden email]> wrote:

Oh, so that's my problem then, I see the sequence of import:'s as
defining the search path, just like in Java imports.  I fail to
understand what is different about this kind of import...

....

Ok, I think I got it by asking myself, should Smalltalk be first in
the import list or last?  Answer:  First.  Because you're "building
up" a name space a la inheritance.

And, this gives the ability to override names that might be in Smalltalk..


On Fri, Dec 20, 2013 at 3:56 PM, Bert Freudenberg <[hidden email]> wrote:

On 20-12-2013, at 1:56 PM, Bert Freudenberg <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- On permanent leave of absence from his senses.

On Fri, 20 Dec 2013, Chris Muller wrote:

> Oh, so that's my problem then, I see the sequence of import:'s as
> defining the search path, just like in Java imports.  I fail to
> understand what is different about this kind of import...
>
> ....
>
> Ok, I think I got it by asking myself, should Smalltalk be first in
> the import list or last?  Answer:  First.  Because you're "building
> up" a name space a la inheritance.

It shouldn't be imported at all. I think the only reason why an
environment is importing itself is to make the lookup in #bindingOf:
work. But since we have to change the binding lookup - because it's the
source of all kind of bugs - we can easily get rid of importing self.
You don't want a class defined in your environment to be shadowed by
another class from an imported environment, do you?


Levente