Lambda the Ultimate

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.

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.

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).

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

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.

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.

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.

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.

Every game object would be able to mutate, thus

PlayerObject could learn how to 'Knit' from OldLadyObject.

Sort of genetic objects :-)

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

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