Does anybody thought about having ...

Alexandre Bergel bergel at iam.unibe.ch
Fri Nov 19 00:11:39 UTC 2004


Hi!

> >I do not like the multidispatch of slate but this I like.
> 
> It's your loss. ;-) The multiple dispatch makes most of the really 
> interesting collaboration code a breeze and allows us to do things 
> which I always thought Smalltalk should be able to do but no one ever 
> conceived to actually do. Run-time scope generalization of this 
> dispatch setup also allows us to do "subjective programming" cheaply, 
> which gets us AOP features without a lot of hassle (though we still 
> don't have generalized join-points).

Can you provide an example ? I was always sceptical about multidispatch. When I read the work on Cecil and MultiJava I do not see some really good example that make me say "Oh yes, I want this language feature!".

I am really curious to see how MD bring more expressiveness.

Cheers,
Alexandre


> 
> >>We're still working on the Squeak-1.0 level of support,
> >I do not understand the squeak-1.0 level support?
> 
> What's missing are: a no-brainer windowing / graphics system (mostly 
> the input/event-handling is what's missing), full browser and inspector 
> framework, and reliable source database. It takes time to build these 
> things, especially when the point is to take Squeak ideas (even 
> non-core ones) and generalize them. Right now the work is on the UI 
> native bindings and the concurrency system (E-style; it seems like 
> everyone's doing it nowadays).
> 
> >>but the basics all work well. We even recently have incorporated some 
> >>of the Squeak-Traits research work to make our mixins safer.
> >
> >can you elaborate a bit on that?
> >Why safer? more robust to changes? Do you take advantage of traits in 
> >your library?
> 
> To be clear, we already had MI, so everything had some kind of traits. 
> Actually, our multiple-inheritance / mixin system protocol was abstract 
> enough that we just changed the underlying workings a bit to allow for 
> Traits-style composition adjustment, and then removed kluges which we 
> needed for proper overriding in the prior default multiple-inheritance 
> semantics. So the end-user gets the same interface, but more control.
> 
> It's safer because we now have controls over the composition of 
> behaviors beyond adjusting the inheritance graph (a Self idiom that we 
> had started with for ease of implementation, and have been wanting to 
> toss aside - as I said our API abstracts over this for most use-cases).
> 
> We can now perform the kind of requires/provides-logic that is done in 
> the SCG work, and have each traits able to re-order its sub-traits for 
> particular behavioral compositions.
> 
> Think about it: for us, we are moving from pure multiple inheritance 
> (which we never liked) to the SCG's Traits model, rather than 
> Smalltalk's single inheritance (which is usable but limited) up to said 
> model. So our move is for safety, not expressiveness in the technical 
> sense.
> 
> --
> Brian T. Rice
> LOGOS Research and Development
> http://tunes.org/~water/
> 
> 

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.iam.unibe.ch/~bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



More information about the Squeak-dev mailing list