Does anybody thought about having ...

Brian Rice water at tunes.org
Thu Nov 18 22:37:44 UTC 2004


On Nov 18, 2004, at 2:17 PM, stéphane ducasse wrote:

>> Slate has this. &foo: arguments specify optional named arguments for 
>> methods and blocks, and *rest parameters allow you to grab any 
>> "run-over" arguments to a block or method in an array.
>
> cool.
> 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).

>> 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/




More information about the Squeak-dev mailing list