About removing global variables

stéphane ducasse ducasse at iam.unibe.ch
Wed Dec 1 10:25:45 UTC 2004


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.

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
	delegate from systDic to it
	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.

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!

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

	This follows also the eclipse practice to not use import* but named 
imports

-      second imports only work at namespace level

		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

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

-      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" :)

Stef




More information about the Squeak-dev mailing list