Jecel Assumpcao Jr wrote:
For Neo Smalltalk I took this suggestion seriously and eliminated inheritance. An object is just a list of "facets" (they don't have the fancy dependency stuff that traits do so it is better to have a different name). Since this isn't running I don't have any actual experience with this style or programming yet. But based on a few years with Self I plan to keep these facets as few and as large as possible. In fact, the idea is to have a single facet for an object until I need to share a part of it but not the rest and then I plan to refactor on demand, splitting the facet as needed. So the result would be an implementation driven factoring and not on a purely logical design.
That sounds like a pretty reasonable route too.
In one tiny bit of experience I've had designing a small trait, which was just a bit of functionality (4 methods or so) that I needed to share between two classes, I found myself creating something so tiny and specific that while readily understood, it wasn't readily summarized, because there wasn't much meat to hide.
But I'm not sure. It might turn out that once we learn to name these meaningfully, they'll be useful. For example, it might make sense to simply remove method categories completely, and replace them with Traits. Never really liked method categories. Because they have zero semantics there is even less basis for designing them than there is for Traits (at least one can minimize boundaries).
One benefit is that it would simplify the browser more or less to where it used to be. BTW, is it very confusing to have the class inheritance hierarchy and the trait hierarchy going in the opposite directions?
Daniel
squeak-dev@lists.squeakfoundation.org