#9 lack of subclass must implement (abstract) or a non-inheritance category-type (trait)

[Anonymous]

Originally created by: grshiplett

What steps will reproduce the problem?
1. reviewed docs
2. cf  http://scg.unibe.ch/research/traits
3. cf Self, LivelyKernel, Pharo Smalltalk, Scala

What is the expected output? What do you see instead?
Alternative to deep hierarchies - particularly relevant for building a flexible web content server framework ( SGML-type content rendering determined by Trait ClosedTagMarkup versus Yaml- or reST-type rendering) with focus on content identification by str comp

What version of the product are you using? On what operating system?
2.4

What C compiler are you using, and what version?

Please provide any additional information below.

While multiple ineritance may be seen to relieve the need for an interface mechanism (e.g. Java interfaces) the objective of Traits is modeling behavior across types sharing a categorical aspect rather than a generic similarity. In Curl (www.curl.com) with multiple inheritance, such mixins are achieved using abstract classes which permit method implementations (a class is abstract if a single method is declared abstract) but the mechanism remains one of inheritance.  In recent yeras, deep hierarchies have been recognized as an issue in mature smalltalk libraries in which behavior variants have always meant sub-classing (no over-loaded method signatures permitted.)  Composition is now seen as preferrable to subclassing - and the maxim becomes: 'program to the interface.'  In Curl, with multi-inherit but no overloading, the challenge was already addressed with mixins.  The Pharo Smalltalk solution is particularly elegant but thus far not adopted by advanced Smalltalk web frameworks such as Seaside.
Self traits were recently revived as Lively-Kernel at SUN and as Avocado JavaScript.  See also: https://code.google.com/p/jstraits/
ref: http://selflanguage.org/  http://lively-kernel.org  http://coolfridgesoftware.com/avocadodev/  http://www.pharo-project.org/home  

[Anonymous]

Originally posted by: grshiplett

notes:
"have always meant sub-classing"
I should have said 'usually' or 'tended to' as there have been other efforts in Smalltalk patterns: double dispatch, Visitor pattern, Decorator pattern (itself a strange/perverse exploitation of inheritance/encapsulation) - and at one time the project SmallInterfaces.
In my current use of Seaside for Smalltalk, the lack of Pharo traits requires repeated needless subclassing and results in ode maintenance issues as seaside evolves to 3.0+
Self is usually seen as a second-generation Smalltalk, as was StrongTalk.  cf Clean Slate Smalltalk http://slatelanguage.org/
Python 3.1 is a very different case.  I view Ruby with mixins as another Smalltalk off-shoot.  Traits are a major feature of Martin Odersky's Scala language.

[Anonymous]

Originally posted by: grshiplett

A version of Traits for a non-procedural (declarative) language: Logtalk "category" for object-oriented Prolog
http://www.logtalk.org

[Anonymous]

Originally posted by: grshiplett

I thought this a useful note for someone new to this issue (but then I have a Smalltalk bias and a Pharo bias at that): http://www.artima.com/weblogs/viewpost.jsp?thread=246488

[Anonymous]

Originally posted by: grshiplett

One way of looking at Traits is as an alternative to AOP (Aspect-Oriented Programming)
to effect both composition and 'separation of concerns'.

Other legacies of the Self language included emphasis on inlining code, since adopted 30 years late by Google V8

Three lessons of OOP since 1984: use composition; use Traits; do not over-use inheritance.

Multiple inheritance alone is not enough: see Curl language of www.curl.com for their style of "mixins" and their important role in that low-bug evolving library and framework.