About the clean of SystemDictionary

Trygve Reenskaug trygver at ifi.uio.no
Tue Sep 28 16:39:25 UTC 2004


Sounds very good to me. Any cleanup of the basic classes will be most 
welcome. But I cannot see that a quick fix done in a couple of months will 
be a great help. I believe that was how Morphic was introduced in the first 
place to get away from the complexity of MVC. Anyone can see that the 
result is not as clean and simple as originally envisaged. We can always 
hope to find time to clean it up later, but later has a tendency never to 
arrive.

Don't make the same mistake again. Architectural principles should come 
before design. Design should come before coding. And why be backward 
compatible? Squeak can support several disjoint class libraries. Old code 
work with the old libraries, new code with the new. So I suggest that you 
will be better helped with two parallel development paths: One incremental 
bug fix etc, another creating the new stuff. And spend the time to get it 
right first time.

For my BabyUML experiments, I have implemented a new MetaMetaclass 
(instance of itself), a new Metaclass that is instance of MetaMetaclass, 
and new classes that are instances of Metaclass. I also work with a new 
MetaComponent, instance of MetaMetaclass. Instances of my new classes can 
happily work with instances of the common Squeak classes since they use the 
same VM. But I clearly see that the realization of a clean class library 
will take years, not months.

Good luck
--Trygve


At 28.09.2004 17:13, you wrote:
>Hi all
>
>we the KCP team are cleaning the kernel of squeak not for fun nor for the 
>beauty (ok sometimes I think that
>we need beauty to dream about new languages since they should be even more 
>beautiful). Now we would like to have
>squeak as a system that can mutate over the next 20 next years. We want to 
>use squeak to dream about new languages
>and so on. For that we need clean code (such as the AST visitor because to 
>check literal or whatever we do not want to
>have a recompile and fix ugly code everywhere).
>
>Now we would like to be able to define new kernel inside squeak: yes a 
>different Object and Class classes.
>for that we need to clean SystemDictionary but we would like to avoid to 
>impact anybody else and
>still have a good system at the end.  After trying last year (with some 
>successes and some lose of brain cells
>for example Beeper), we would like to fix that class once for all.
>
>Here is the plan:
>         - 1 introduce a clean namespace class:
>                 (warning warning not something complex, no composition, 
> no nesting, no inheritance....
>                 just a class that holds binding but does not inherits 
> from Dictionary and has a cool interface and not 12 responsibilities)
>
>         - 2 delegates from system dictionary to it
>                                 Namespace smalltalk would return Smalltalk
>
>         - 3 fixes all the ugly Smalltalk at: ...to use the new interface 
> of Namespace but keeping the old ones in SystemDict
>         so that people can still load their code without any problems
>
>Note that point 4 and 5 should be atomic
>         - 4 deprecate everything "move" **everything** from 
> SystemDictionary to SmalltalkImage and other classes
>         - 5 then introduce Smalltalk as a pointer to SmalltalkImage default
>
>this way after this period of time:
>         - Smalltalk will work for old code
>         - Smalltalk will be not a subclass of Dictionary
>         - We will have a clean Namespace and the tools using it
>         - And Smalltalk/SmalltalkImage will be clean.
>
>So we are looking for feedback.
>
>Stef
>
>
>


-- 

Trygve Reenskaug      mailto: trygver <at> ifi.uio.no
Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
N-0378 Oslo           Tel: (+47) 22 49 57 27
Norway





More information about the Squeak-dev mailing list