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