Lambda the Ultimate

inactiveTopic Inherited Traits - Classes Like Never Before
started 9/11/2003; 10:28:05 PM - last post 1/26/2004; 9:14:18 AM
Mark Evans - Inherited Traits - Classes Like Never Before  blueArrow
9/11/2003; 10:28:05 PM (reads: 19863, responses: 13)
Inherited Traits - Classes Like Never Before

Despite the undisputed prominence of inheritance as the fundamental reuse mechanism in object-oriented programming languages, the main variants--single inheritance, multiple inheritance, and mixin inheritance--all suffer from conceptual and practical problems. In the first part of this paper, we identify and illustrate these problems. We then present traits, a simple compositional model for structuring object-oriented programs. A trait is essentially a group of pure methods that serves as a building block for classes and is a primitive unit of code reuse.

The purpose of traits is to decompose classes into reusable building blocks by providing first-class representations for the different aspects of the behaviour of a class. Note that we use the term "aspect" to denote an independent, but not necessarily cross-cutting, concern.

Which statement addresses AOP similarities in a nutshell. There is a possibly related paper, "Half & Half: Multiple Dispatch and Retroactive Abstraction for Java," from the Brew Project.


Posted to OOP by Mark Evans on 9/11/03; 10:41:23 PM

Mark Evans - Re: Inherited Traits - Classes Like Never Before  blueArrow
9/11/2003; 11:00:17 PM (reads: 1231, responses: 0)

The term 'inherited traits' is an English idiom and contextual pun that I couldn't resist, but may be too clever by half. Sorry for any confusion. Ehud can put "(Un-)" in front of the title if complaints come in.

I am very curious to hear what LtU folks think of traits.

water - Re: Inherited Traits - Classes Like Never Before  blueArrow
9/12/2003; 12:39:54 AM (reads: 1202, responses: 0)
I've been following this research for a year now in the context of Squeak and Slate (I met Nathanael at OOPSLA '02 and went over it in detail there). The interesting features are that (1) composition is modular, (2) traits-style mixins don't add state, and (3) it's very straightforward to flatten the traits compositions and verify consistency statically. As a nice result, it fits in with tools and users that expect a single-inheritance model. I don't understand why the term "aspects" is used, since Nathanael has mostly described it in terms of components of behavior rather than aspects.

I don't see any strong relation to Half & Half at all, though: there's no relation to multi-methods in the Traits work and the extension mechanism is not retroactive, and neither does it deal with the addition of state. To be clear, Traits are components, not extensions.

Isaac Gouy - Re: Inherited Traits - Classes Like Never Before  blueArrow
9/12/2003; 9:04:36 AM (reads: 1113, responses: 0)
Maybe Traits will appear in a commercial Smalltalk implementation and previously on LtU

Mark Evans - Re: Inherited Traits - Classes Like Never Before  blueArrow
9/12/2003; 11:09:14 AM (reads: 1085, responses: 0)

Sorry for the duplication then, Isaac. It looks like LtU's search engine needs improvement? I tested 'Traits' in both boxes before posting, and came up empty as regards this work. But sure enough, the archives have the clues. Next time I will look there first.

I don't see any strong relation to Half & Half at all, though: there's no relation to multi-methods in the Traits work and the extension mechanism is not retroactive, and neither does it deal with the addition of state. To be clear, Traits are components, not extensions.

The connection was speculative on my part, and I wanted to introduce Half & Half on its own merits, as a bonus prize. Consider however that multimethods are another coin with which to purchase 'open classes.' From that standpoint, which technique is superior? Would you rather work in a multimethod-capable class hierarchy with inheritance (of some form), or with Traits?

On the other tack, the connection with software components ties in with the previous PyUNO topic, another reason I posted Traits yesterday. Does anyone have some wisdom about that connection? Or am I just seeing things? Component interfaces define behaviors, and:

I don't understand why the term "aspects" is used, since Nathanael has mostly described it in terms of components of behavior rather than aspects.

The extract also suggests more generality for Traits than (merely) the "cross-cutting concerns" of AOP. That extract was chosen in an attempt to highlight this difference with AOP. Peter Van Roy considers AOP just so much hype. Personally I am more interested in possible component and multimethod connections to Traits (in the motivational if not the implementation sense).

Isaac Gouy - Re: Inherited Traits - Classes Like Never Before  blueArrow
9/12/2003; 11:48:48 AM (reads: 1081, responses: 0)
multimethods are another coin with which to purchase 'open classes.'
Looked at Nice?

Brew
Seems that they also intend to provide 'a representation of classes as first-class objects' - metaclasses again...

water - Re: Inherited Traits - Classes Like Never Before  blueArrow
9/12/2003; 3:49:02 PM (reads: 1054, responses: 0)
The connection was speculative on my part, and I wanted to introduce Half & Half on its own merits, as a bonus prize.

Yes, it is interesting...

Consider however that multimethods are another coin with which to purchase 'open classes.' From that standpoint, which technique is superior? Would you rather work in a multimethod-capable class hierarchy with inheritance (of some form), or with Traits?

Well, they don't conflict, and in fact I would like to use both. They're compatible in that the Traits system encourages (but does not demand) a certain amount of type-safeness, and multimethod dispatch generally requires more consideration about types to be safely useful. Type-safeness often requires dealing with multiple inheritance of some form or another, and Traits are a relatively safe and sane way to accompish this.

(Disclaimer: I work on a multimethod-enabled Smalltalk dialect to which I would like to add the safety of Traits to my multiple-inheritance setup.)

As for extending classes, Traits provide a disciplined extension of behavior without state, and can determine at composition-time what parts of the behavioral interface are missing. This is because Traits only depend on and provide behavior. Unfortunately, some of the requirements may include state, and so violate some encapsulation of the closed class you compose with.

If your subject matter is entirely contained within Java, the benefit is that Traits as behavioral components define a single point for a basic behavioral implementation of an interface. However, it's also often true in practice that this default implementation should and will be overrided by the class that resulted from the composition.

As for AOP, my opinion is that it's mostly a very specific characterization of a more general, powerful, and safe idea that has only been hinted at in the literature. I've looked at two papers and an implementation (in Squeak, actually) of a more general system, but these have not really been considered by a wide enough audience yet.

I would not try to draw a relation between Traits and AOP, but instead simply describe it as it is: a meta-level component system for behavior.

Mark Evans - Re: Inherited Traits - Classes Like Never Before  blueArrow
9/12/2003; 6:20:49 PM (reads: 1031, responses: 0)

Right. I was trying to highlight that Traits are not AOP.

Looked at Nice?

Nice I have known about (and admired) for a long while. In the multimethod department, we also have Needle coming strong, seen on LtU before. However what I'm seeking is not language advice, but a more abstract comparison of open-classes-via-Traits vs. open-classes-via-multimethods as a programming technique. What 'water' says is that he would like to have both available, meaning that both have their uses, I take it.

Then there is the whole Component Object Model (COM) business of interfaces. So I am also interested how those compare and contrast with Traits.

Thank you, 'water,' for your input. I may have more to say about Traits later.

Neel Krishnaswami - Re: Inherited Traits - Classes Like Never Before  blueArrow
9/13/2003; 3:54:25 PM (reads: 954, responses: 0)
Another language worth looking at is John Reppy's Moby language. It uses a parameterized module system to get the effect of traits -- you can define a parameterized module that takes a class as an argument and then subclass that class as part of module instantiation. It's a very slick piece of design, which automates a vast amount of boilerplate inheritance. <http://moby.cs.uchicago.edu/>

Mark Evans - Re: Inherited Traits - Classes Like Never Before  blueArrow
9/13/2003; 6:16:06 PM (reads: 949, responses: 1)

Speaking of multimethod languages, I wonder if Ryan has news on Mica to share with LtU.

The relevant Moby design paper shows how Moby can reproduce C++ and Java classes (elegantly, with orthogonal class and module systems). Neel, would you care to show in code how Moby can reproduce Traits? Your explanations are always helpful, clear, and concise.

xeo_at_thermopylae - Re: Inherited Traits - Classes Like Never Before  blueArrow
9/13/2003; 9:46:55 PM (reads: 931, responses: 0)
PowerBuilder has had "traits" for years. The PowerBuilder Foundation Class (PFC) libraries use what they term "delegation", which is the same as "traits" described above (although in other languages it is called "composition" or "service based architecture").

PowerBuilder was having the usual problems with inheritance. The PFC libraries provided a framework that allows essentially what traits do. It's very lightweight and more flexible than inheritance. It should be straightforward to add to any OOP-capable language.

Lyndon - Re: Inherited Traits - Classes Like Never Before  blueArrow
9/23/2003; 11:05:59 PM (reads: 643, responses: 0)
Reminds me of my oft daydreamed about, never implemented multi player role playing game.

Every game object would be able to mutate, thus

PlayerObject could learn how to 'Knit' from OldLadyObject.

Sort of genetic objects :-)

Isaac Gouy - Re: Inherited Traits - Classes Like Never Before  blueArrow
1/24/2004; 2:46:17 PM (reads: 190, responses: 0)
Neel, would you care to show in code how Moby can reproduce Traits?

"A typed calculus of traits" Kathleen Fisher, John Reppy

Isaac Gouy - Re: Inherited Traits - Classes Like Never Before  blueArrow
1/26/2004; 9:14:18 AM (reads: 152, responses: 0)
And it turns out that Scala has Traits, and Nice Interfaces can contain method implementations (as well as declarations).

So it's not difficult to gain experience programming with Traits.