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
|