[squeak-dev] Re: Package unload status

Juan Vuletich juan at jvuletich.org
Sat Jan 9 12:27:48 UTC 2010


Andreas Raab wrote:
> 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)

This is easy to do in any way. I'd be changing a lot in Morphic during 
the next months for Morphic 3, so I'd do that later, when protocols in 
Cuis start to stabilize.

>> 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 :-)

Mhhh! I think the name "Morphic 3" makes sense, as it all started after 
suggestions from John Maloney (in SqueakNews) and Dan Ingalls (in "Where 
is Squeak headed"). But I agree with your reasons too. So far, the name 
of the framework is "Morphic 3" and the root class is M3Morph (which I 
don't really like). Maybe I'd come up with a completely unrelated name. 
Perhaps "CuisGraphics" or something... Suggestions welcome!

Cheers,
Juan Vuletich

> Cheers,
>   - Andreas




More information about the Squeak-dev mailing list