[Prev][Next][Index][Thread]
Re: MI: why?
Terry Raymond <traymond@craftedsmalltalk.com> wrote in message
news:85ofs1$rg7@nnrp3.farm.idt.net...
> >
>
> Well, I have seen plenty of cases with Smalltalk where I wished
> I had MI. However, my experience with MI was with using
> mixins which tended to be light weight. I think MI is like any other
> tool, if you misuse it, it will cost more than it is worth. In general
> it is better to look for solutions without MI, but there are those few
cases
> where MI wins by a long shot.
>
My experience is too limited to make much of a contribution.
But, I have been frustrated with the Smalltalk Collection classes,
wonderful as they are. I use OrderedSets, OrderedIdentitySets
and the like, they're ugly in SI, and I wish we could reinvent the
Smalltalk collection inheritance hierarchy. I tried
some baby steps with delegation and wrapping and it stunk (I really
didn't have enough time to do it justice. This is an entire PhD
worth.) I'd like to create a Collection by specifying any number of the
various "types" or categories in combination. Say:
CollectionFactoryClass
new: aSize
ordered: orderedBoolean
fixedSize: fixedSizeBoolean
duplicates: duplicateBoolean
sorted: sortedBooleanOrSortBlock
indexedOrKeyed: indexOrKeySomethingOrOther
and anything else I've missed. You get the point I hope.
I'd love to see this in Smalltalk and if it can be done elegantly
in SI that's wonderful. But I will say that I took a peek at the Eiffel
classes and their use of MI for collections was really, really impressive.
My time was limited so my review was superficial. But still, all I know
is that I'm on the fence about this and I'm not convinced with the
SI-only argument. I can only think of ugly solutions to the above problem.
OTOH, I wouldn't be surprised if there *was* an elegant SI solution.
Any PhD wannabees out there looking for a really great subject?
References: