Juan Vuletich wrote:
> Andreas Raab wrote:
>> Juan Vuletich wrote:
>>> BTW, in Cuis, Morph will eventually have a lot less than 500 methods. 
>>> I hope to get to about 200.
>>
>> Very nice. It's extremely valuable to have someone with a real 
>> interest in making things smaller. Coincidentally, I'm quite okay with 
>> the idea that Cuis will always have a smaller image than a core Squeak 
>> image would be. I think the important part is to have reasonable 
>> compatibility betweeen the two. I want compatible kernel interfaces, 
>> compatible collection libraries, compatible morph protocols. In other 
>> words, anything built for Cuis should run on top of Squeak without 
>> changes.
> 
> Interesting. So far I have only thought about how Cuis could support 
> stuff meant for Squeak!

Sure, it does go both ways - but what I meant to say is that Squeak = 
Cuis + X so naturally everything that works in Cuis will work in Squeak 
but only stuff in Squeak that doesn't use X will be able to run in Cuis. 
Where X might be something like MC + M17N + MorphicPlus or something 
like that.

> WRT compatibility of apps with Squeak, I believe Cuis packages will fall 
> in 3 categories:
> 
> 1) Stuff that is identical (almost) to Squeak. For example, I took the 
> current Compiler categories and  Kernel-Methods to support closures. 
> Kernel-Classes, Kernel-Objects, Kernel-Numbers and all Collections- 
> categories could follow. These are parts of the system that are in good 
> shape in Squeak, and have people doing great work there too. Stuff I 
> can't really improve.

Agreed.

> 2) Stuff that I have somewhat modified. I removed lots of protocol. This 
> obviously doesn't affect porting Cuis apps to Squeak. But I also removed 
> arguments, making some messages shorter, and added some convenience 
> methods. This is easy to address by adding an optional 'Cuis 
> compatibility' package for Squeak.

Let's not. Let's make sure Squeak support these protocols natively and 
build the next layer on top of it. In fact, that might be something you 
could start helping with today. Remember, if we end up with Squeak = 
Cuis + X then we can have our cake and eat it too - a nice, small 
microkernel and more stuff built on top of it.

(if you feel more comfortable adding this as a Cuis extension, feel free 
to do so, but I don't think it's necessary)

> 3) Stuff that is really different. For example TextStyle, and the new 
> TextEditor application. (I'm not talking about the Editor hierarchy 
> here. In Cuis do World/Open/Text Editor. I also have a fairly complete, 
> not yet released, style based text editor.) These might need being 
> ported to Squeak and will give some work. I could also include Morphic 
> here. But I also hope to replace the current Morphic in Cuis with 
> Morphic 3. And I also hope to be able to make Morphic 3 an optional 
> package for Squeak and Pharo.

The one thing I'd recommend is not "reusing" existing namespaces. If you 
have a new UI framework, don't call it "Morph" or "Morphic". This only 
leads to confusion down the road since it can't be loaded side-by-side 
with Morphic. Anything you do in a separate namespace won't be a problem 
- we've already agreed how to deal with the underlying basics so 
basically this is just another application on top of Cuis which can be 
run on top of Squeak :-)

Cheers,
   - Andreas