On Saturday, September 6, 2003, at 11:37  AM, ducasse wrote:

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

Huh? I've heard the term SqueakScript get toss around here a couple of 
times, but never encountered Diamond or Sapphire. Can you point me 
toward more information?

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

Well, I'd be interested to see where that research led.

On a more pragmatic level, I think this is completely applicable to the 
Squeak kernel, without changing any of the semantics of Smalltalk. 
Refactoring the kernel's scoping mechanisms needn't change the 
programmer's view of class variables, pool variables or globals.

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

Well, yes, you do need syntax for these things in your package file out 
formats, but that's easy. What's hard is supporting them in the kernel 
and IDE.

>> 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).

Exactly. In fact, it's so important that it really does need to be part 
of the kernel and standard IDE. Packaging systems should not have to 
modify the kernel or supply their own IDE just to work reliably.

Colin