On Saturday, September 6, 2003, at 03:39  AM, ducasse wrote:

> 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?

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.

This also ties into another thing I'd really like to see, which is 
initialization and finalization expressions. 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?

Colin