As a non-Smalltalk/Squeak-oficionado I will chime in here...

I personally don't like the idea of aliasing because (if I understand
you correctly) I believe it will make it very hard on the "casual user"
(I am one of them).  I have used many Smalltalks (in a casual way:) and
one reason I have stuck to Squeak (or Squeak has stuck to me?) is its
overall environmental simplicity.  It just scares the wits out of me
that I might file in someone's code and have to decide to which class an
alias refers --> "I don't know, I didn't write the code; why didn't the
author do that decision process for me?"  Decisions like that generally
result in me not filing-in the code.

On Thu, 2004-04-08 at 09:17, goran.krampe at bluefish.se wrote:
> Hi!
> 
> Noury Bouraqadi <bouraqadi at ensm-douai.fr> wrote:
> > Hi,
> > 
> > Goran, I like most of what you proposed.
> > After reading Andreas answer, I started thinking about imports.
> > I belive that to increase reuse opportunities imports should not be 
> > bound inside namespaces.
> 
> Right now we have some confusion of terms. If a namespace is the "named
> list of names" and not the "Andreas-context", then I agree. :)
> 
> > Instead, when loading a namespace into an image, one should be asked to 
> > link names
> > that are not resolved inside the loaded namespace with objects available 
> > in other namespaces
> > already in the image.
> 
> That is how I would want it to work I believe, reading on...
> 
> > Example
> > Suppose I have namespace A providingclasses L and M.
> > Then I load/create namespace B where X and Y are not bound.
> > System should ask me wich classes to use for X and Y. I can choose
> > to L and M. Then X and Y in namespace B are just aliases to L and M.
> > 
> > Now, I "fileout" my namespace B so it can be used in another image 
> > (Andreas, should I talk about
> > another "context"?) with two namespaces C and D. Suppose that C holds a 
> > class Z and D holds
> > a class W. Here, I can bound X and Y of namespace B to Z and W (that are 
> > in two different
> > namespaces).
> 
> Hmmm. Ok, I think I understand your model, response below.
> 
> > To sum up, what I suggest is:
> > -a namespace should state what it needs, but not from where to get it 
> > (no hardwired import).
> 
> That would be equal to my proposal. With the difference that the source
> has qualified names - but we could (future extension) allow "aliasing"
> between prefixes - like saying that - ok, from now on Tweak:: maps
> instead to HackedTweak:: in this image. I don't like aliasing "per
> class" because I don't think a class should ever be used with another
> name than the author gave it - it would cause tremendous confusion.
> 
> > The location (namespace) of imported classes 
> > should not be visible in the code inside namespaces (so no need of extra 
> > syntax stuff and source code never change).
> 
> Note: In my solution source code doesn't change either. It just
> "renders" differently in the viewers. It's like the alternate syntax
> switch or whatever.
> 
> > But, one should be able to 
> > findout connections between namespaces.
> 
> That seems very reasonable. And trivial in my proposal I think.
> 
> > -allow refering to classes with different names (aliasing). This means 
> > not rely on names for retreiving classes required by some namespace. In 
> > order to keep the "optimistic" approach of Goran, this should be viewed 
> > as an extra possibility. When loading a new namespace, the system can 
> > try to fulfill requirements based on class names, but one should be able 
> > to refer to classes with different names.
> 
> I am sorry, but I really don't agree on this last one - aliasing is IMHO
> a BAD idea. It just widens the gap between "what I read" and "what it
> is".
> 
> But your post made my thoughts even more clear. :)
> 
> > Noury
> 
> regards, Gran
-- 
Jason Rogers

"Where there is no vision, the people perish..."
Bible, Proverbs 29:18