Need feedback on one idea

ducasse ducasse at iam.unibe.ch
Sat Sep 6 19:43:12 UTC 2003


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

Sapphire was the name that dave thomas gave for a new Smalltalk he 
envisioned at ESUG 2002 the slides are googeable I'm sure.

Diamond was the name we choose to talk about this new stuff we could 
build here between the guy of berne.


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

Yes interesting point I note that but this would be even better we 
would get a simpler model. but we have to play with that to know if 
this is worth.

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

Yes but as Squeak does not have a clean kernel and that package needs 
that I would like to see what joseph and ginsu freak can produce to 
include it into the kernel instead of inventing it myself. But the 
point is taken for the future KCP stuff even if I would like to focus 
on really dirty parts for now.

Stef



More information about the Squeak-dev mailing list