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
|