Traits approaching mainstream Squeak
daniel.vainsencher at gmail.com
Sun Aug 28 06:46:44 UTC 2005
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?
More information about the Squeak-dev