About removing global variables

goran.krampe at bluefish.se goran.krampe at bluefish.se
Wed Dec 1 12:49:34 UTC 2004


Hi!

=?ISO-8859-1?Q?st=E9phane_ducasse?= <ducasse at iam.unibe.ch> wrote:
> hi goran
> 
> I have to reply to your namespace proposal: We looked at it (marcus, 
> me, alex, nathanael....the scg people).
> and we do not like it.

Hehe, ok. It would be nice to hear more details though. ;)
 
> Now what we are doing is NOT TO INTRODUCE NAMESPACE IN THE LANGUAGE but 
> to have a class
> to remove the mess inside the system. In fact systemDictionary and 
> environment where namespace but they got so corrupted that we stopped 
> thinking that we could fix them.
> 
> So what we are planning to do is:
> 	introduce the class namespace

Fine. Though I may be lost about the use of it if you are not going to
make it acc

> 	delegate from systDic to it

To "it"? An instance? Multiple instances?

> 	fix all the caller to call namespace instead (via self class 
> environment)
> 	reunify SmalltalkImage with SystemDictionary because this is what 
> SystemDictionary is.
> 
> At the end we should have
> 	- a class namespace
> 	- systemDictionary -> SmalltalkImage and SmalltalkImage current == 
> Smalltalk
> 	- the possibility for people to experiment with new kernel
> 	- the possibility if we decide to do it to introduce Namespace at the 
> language level but this is not clear
> 	if we want that.
> 
> Now you can have a look on the namespace code that we publish on 
> squeaksource. This is publicly available and
> not secret.

If I get time, sure.

> We did several implementations and also capitalize on what we learn 
> with classboxes and imports: in C++, Java
> and VW and linearization failure of CLOS, and C++ constructors and 
> traits conflicts resolution.
> 
> Our idea is that we want to have a namespace CLASS so that we could 
> create new kernel.
> This is also to clean the core of Smalltalk. But again not introduce 
> namespace in the language!

Not sure what that means. I mean, what good is the class if it isn't
used?
Or perhaps I am missing something.

> Let us join effort. :) If you want to help CLEANING SystemDictionary 
> and related and introducing this class
> there is a lot of work to do. I started to really evaluate what have to 
> be done.
> 
> >> Now if we would introduce namespace at the language level, we would 
> >> not allow method body
> >> code to escape their scope using :: kind of bad operator.  We prefer 
> >> having flat space and
> >> namespace only at the border (ie import statement of the namespace).
> 
> The idea is the following:
> 
> - 	first no namespace import (klaus from Smalltalk/x explained to me a 
> nice VW bug
> 		N1 import N2* and N3*
> 
> 		N2 define A
> 		N3 define B
> 		
> 		In N1 Z refers to B
> 
> 		then later we change
> 		N2 now has another B
> 		then you recompile 6 months later and your method in N1 Z and booum 
> you
> 		refer to N2 B

Notes that the above issue wouldn't happen in my solution either. :) In
my solution there are no imports and all references are direct - as
today.

> 	This follows also the eclipse practice to not use import* but named 
> imports
> 
> -      second imports only work at namespace level

Thank god. ;) Even though I still favor not having them at all.
 
> 		N1
> 			import: A from: N2
> 			import: B from: N3
> 	
> -      third in the code inside N1 I can only see A and B I do not see 
> namespaces or outer names

Seems right.

> -      fourth the tools should produce as in eclipse the import 
> statements
> 	          (we could have also imports: {A .C} from: N2

So... hmmm. The summary of this sounds very much like my solution (yes,
really). Your references are also "direct" - the only difference is that
you have split the reference in two parts. The first part is the actual
reference in the code where you type "A", and the second part is the
import which basically says that "A" means "N2::A".

In my solution I don't split it - I just always keep the reference in
the code as "N2::A". In fact, my solution has an "edge" over yours in
that I can actually both use "N2::A" and "Z::A" just fine. I assume you
then need to do some ugly aliasing or something?

Again, I urge you to really question what IS an import? IMHO it is just
a way to avoid typing long names, especially since you don't allow
*-imports. And then I don't understand why you really *need* them. :)

Another way to see my point is that given your model and smart tool
support - the user will never see those imports. Or at least I assume
you want that to be true. Then... what is their use? :)

> -      fifth conflicts are always resolved explicitly like in traits, 
> order or precedence
> 	is not a really good idea because there is always a limit case (CLOS 
> inheritance, C++constructors,
> 	mixins, showed the limits)
> 
> 	we summarize that as "a flat world for the class coder but with 
> namespace at the borders" :)

Well, I would like to hear the arguments why you don't like my solution.
:) Perhaps it will make it easier for me to understand.

> Stef

regards, Göran



More information about the Squeak-dev mailing list