On 9/6/07, Klaus D. Witzel <klaus.witzel at cobss.com> wrote:
> On Thu, 06 Sep 2007 18:27:50 +0200, Jason Johnson wrote:
>
> If nobody tries then the opposite "not found to be usable in practice" is
> equally far away?

I thought about this thing with traits that keeps coming up on my
train ride home and I think I see the problem.  I don't know what kind
of thesis Alejandro has planned, but I have a quite radical suggestion
that might make a good one. :)

Framing The Situation

As anyone paying attention knows, Andreas is probably the loudest
voice challenging Traits with the hard questions/comments, and I am
one of the louder people (in general but also) defending it.  He comes
with things like "it is basically MI again" and "it makes things more
complex then it solves", and I answer with my sole defense: it makes
sense for Magnitude.

But does it?  Of course in Haskell it's beautiful, it makes sense and
"just fits".  But Haskell isn't an OO language.  In Haskell most of
the code you write wont be overriding anything or using anything
remotely resembling an object.  So when you *do* actually make a type
class it's not too much to ask to put in all the "deriving(Eq, Ord,
.." every time because you just don't do it that much.

But in Smalltalk *all you do is objects*.  So using my example of
Magnitude, how exactly would that work?  From an entity design, it's a
no brainer that equality is a trait and comparability is a trait.  But
once you have those 2 traits, how do you use them?

(1) You could use them in Object so that all objects get the benefit,
but if then why bother with the traits?  Just leave it as object
methods.  (2) You could create an object at a high level that uses
them, lets call it... Magnitude for example.  Then objects that
implement these traits can inherit from it and those that don't can
inherit elsewhere.  But this is where we are today.  (3) Lastly, you
could just have every single (base) class in the image use the traits
that apply to it explicitly.  Now that's a lot of typing.  We're not
in Haskell where a big project may have 10 classes total.

So it would appear that due to the single inheritance, OO nature of
Smalltalk and the fact that Traits are not stand alone entities
themselves, there is no good way to actually use them despite their
theoretical practicality.

The Solution?

Or maybe we have just been thinking too small.  Perhaps the way to
think of Traits in Squeak is as first class object protocols (or
interfaces).  Perhaps thinking of Traits as something that comes up
every once in a while (and appear to not work even in that case) is
the wrong way to go.  Perhaps we should decide to put them everywhere
and completely change our browser to support this radically different
way of writing Smalltalk code.

Suicide mission

My suggestion would be that who ever wants to make a thesis download a
stock Squeak image and make a forked "Traits" image to test out this
experiment.  In this image Equality would be a trait, Ordinality would
be a trait, the "block protocol" would be a trait, being able to
display yourself on a web page would be a trait.  Because Traits would
just be a first class protocol.

But this is a different way to program.  Now you probably select a
class that inherits from the right place, change the name after
"subclass: ", hit accept and you're off.  Now you would also be
dropping in capabilities (traits) to your new class to do most of the
work.  You would get lots of behavior from these first class
protocols, but you would also have to define some of them yourself (a
Trait will be in some cases just a "contract" that you will implement
those methods).

And the tools would have to change.  We've all browsed Object I'm
sure.  And people mention how awful and crowded that interface is.  We
have categories for the methods and that helps a lot.  But I wonder
how many protocols are covered by object?  A protocol can span many
categories.  Imagine if nearly all those methods moved out of object
and into a trait for all those protocols.  Some of those traits would
just have to be used by Object anyway because it ends up answering the
message.  But perhaps lots of them would not, but would be traits that
virtually all classes use (e.g. Equal).  How many methods are in
Object, not because it will receive them, but because it's the only
connecting point for the classes that need them?

Clearly with a new idea of defining classes, the tools would have to
show this.  The Traits or Protocols are now part of the documentation
of the class.  The browser should make you be able to glance at a
class and quickly determine all of it's capabilities (maybe color code
Traits that came in via inheritance).  And we would need "capability
templates" as well.  I wouldn't want to spend 20 minutes dragging
traits onto my new class every time I make one.

Conclusion

This email may sound pretty radical.  It does to me anyway.  But at
this point I think such an experiment is the only way we will ever
answer the question of if Traits can work or not.  I think if we keep
trying to piece-mail them in they are just going to look worse and
worse.  They will just continue to appear as a solution looking for a
problem, yet another way to do things instead something actually
ground breaking.

If you make this fork and do these drastic changes nothing may come of
it.  We may find out that it wasn't a good idea after all.  Or maybe,
just maybe, you'll change the way we Smalltalk.

But without this kind of change I no longer see a way that Traits can
be anything other then what Andreas said from the beginning: MI.