Hi

We thought a lot about architecture believe me :)

On 28 sept. 04, at 18:39, Trygve Reenskaug wrote:

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

but not for the kernel ;(

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

Yes but we have to have results ;)

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