hi Henrick

I'm sorry to contradict you but I'm writing book on Smalltalk and I can tell
you that every non uniform thing in the language or the syntax or even the
practice is a ***pain***.

I like the 0, 1 or infinity principle. Yesterday I was trying to explain
that in the case of Morph we can override initialize but that you have to
check for the other classes. Clearly stupid and boring lack of uniformity.

;(

Stef

I think that small design decisions can have big impacts.



> 
>>> 
>>> I don't like this idea. It sacrifies regularity of the syntax for a tiny
>>> benefit.
> 
> It's always easy to dis an idea, and it's especially easy to dis new ideas
> and say that you like the old way better. It is however more difficult to
> produce better solutions. In particular, the position "I want modules but I
> also want everything to stay exactly the same as it was before" seems to
> come up surprisingly often.
> 
> So, what do you suggest instead? I hope you realize that inter-module name
> references are a new construct, and a new convention is needed for making
> them. If you try to get around this type of reference, you get into a
> bootstrapping problem.
> 
> In general I think Doug's comments were thoughtful and to the point, but I
> have a few additional comments.
> 
> - The doesNotUnderstand: hack is really just a temporary solution. Right now
> unqualified accesses are still allowed to enable old code to continue
> working.
> 
>> This would require that your module imports ("uses") the Morphic-Core-Basic
>> module.  I tend to think that this is probably the best practice of the
>> three... assuming there's some sort of reasonable UI for easily making
>> modules
>> import other modules, etc, in as automated a fashion as possible.
>> 
>> In fact, I'd go as far to say that I would always import modules (like
>> example
>> 3) when writing code, and never use explicit paths in my code, the *only*
>> exception being when there's an actual class name clash in my imported
>> modules, and then of course I would need an explicit path in the code.  (I'd
>> be curious to hear other opinions on this, though.)
> 
> - Importing all names has many problems of its own, and indeed you still
> would need the ability to disambiguate somehow. But it is generally
> considered better practice to be explicit about where a name comes from,
> than to import a name. E.g. when creating Oberon, Wirth removed the ability
> to import names like you could in Modula-2.
> 
> But like I said above, what do you suggest instead?
> 
> Henrik
> 
>