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
|