>> after seeing a talk at ESUG, I was wondering how difficult it would 
>> be to remove classVar and Pool from classes and replace them with 
>> namespace variables. I would like to give a try just to see all the 
>> problems. I already have my own list:
>> 	- I'm not sure I would like to have namespace import for example
>> 	- how to initialize variables....
>
> I like this idea.
>
> I've been intermittently playing around with atomic installation of 
> Monticello snapshots, and it looks like I'll need to use something 
> like this in order to compile methods for classes that haven't been 
> installed yet. The installer would then convert back to class pools 
> and shared pools to play nice with the current runtime.
>
> I think it would be a nice refactoring for the KCP, and by happy 
> coincidence, make it easier to do atomic loading of packages. Here's 
> what I was thinking; Stephane, how closely does this match what you 
> had in mind?

Zero  because I was not thinking about KCP but Sapphire, 
Diamond...ScriptSqueak.. call it the way you want.

If we take Smalltalk and shake it, add some cool stuff like traits, may 
selector namespaces, remove the dirt
and the ugly, what do we get. I would like to give a try to fight a bit 
with Squeak and have that for experimentation.

> When compiling a method, the compiler would no longer ask the class 
> for bindings. Instead, it would ask the class for its namespace and 
> use that to resolve variables. The namespace would be essentially an 
> array of scopes. A scope would be essentially a dictionary, mapping 
> symbols to values. To respond to #bindingOf: the namespace would 
> search its array of scopes for the binding.

Yeap

>
> This also ties into another thing I'd really like to see, which is 
> initialization and finalization expressions.
Exactly. and naturally you will arrive to have a syntax for that.

this is why we need a declarative syntax to declare "global" variables

> They'd be DoIts that get run after the creation and before the removal 
> of a variable. This would give us finer-grain control over 
> initialization than we currently get with class-side initialize 
> methods, and make it easier for packaging tools to bring the image 
> into the correct state automatically.
>
> Thoughts?

This is the right direction. That's why I'm looking to see the next 
open source release of Ginsu for this specific topic.
(I do not if joseph addressed this point but any decent package system 
has or it is not one just a hack that sometimes works).
>
> Colin
>
>