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
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
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
Hi!
This of course brings back the discussions on Namespaces and if you want to I can finally dust off that presentation on it I have and even throw in an hour or two to fix the last "bug" in it so that it actually works in 95% (some tools like for example version browsers etc seems to be slightly problematic).
Interested?
regards, Göran
If you want but we JUST want to have a class that has the responsibility to hold binding with a decent interface. And our point is NOT to introduce namespaces in Squeak. This is totally different. The tools should be using a namespace which per default is Smalltalk but not Smalltalk directly. This is why I removed all the Smalltalk by self class environment long time ago.
Once we will have done that you will be able to apply the same trick you did, I still would like to understand your design But are you coming to OOPSLA? Because I do not work to talk about language design by email this is too frustrating.
So I would prefer not for now so that everybody can concentrate on making progress :). I prefer to know you are working on SM2 this is much more important for me. By the way people told me that we could not use two images in the same directory with sm because the external sm cache files would not like it. Is it fixed? Because else I do not see the point to have a cache. Have you thought also of a solution to have the cache in the image because this means that SM does not work if there is no file for example :) Stef
Hi!
This of course brings back the discussions on Namespaces and if you want to I can finally dust off that presentation on it I have and even throw in an hour or two to fix the last "bug" in it so that it actually works in 95% (some tools like for example version browsers etc seems to be slightly problematic).
Interested?
regards, Göran
squeak-dev@lists.squeakfoundation.org