[Havvy]

I'd consider structs that implement various traits (to use Rust's terminology) to be more of a 'usual' approach to an object model. You can see the approach with mixins in many scripting languages, Rust's entire object model, Haskell's typeclasses, Elixir and Clojure's protocols, ect. ect.

The fact that you can classify things into a classification tree does not mean that the classification is how things actually work. If it so happens that classification trees work for a problem, you can build them with trait inheritance, but structural inheritance hasn't been that useful IME, so the marrying of both types with classical inheritance just leaves a bad taste in my mouth.

[nly]

To have 'structs that implement various traits' you must first have structs. That is, objects with some known immutable shape. Implementing any kind of trait (interface) to an 'object' having a mutable structure (like the dictionaries used for modelling objects in most dynamic languages) would be tricky without exposing some crap to the programmer at the language level. Off the top of my head you'd need at least something like Perls 'bless'[0] coupled with Rusts strong protections against mutation.

Whether you choose to define your classes in the form of (possibly intersecting) sets of objects having some particular trait, or set of traits, or in some taxonomic tree is fairly irrelevant. The difference is largely a matter of taste. I think the point Bob (munificent) is making here is that 'scripting languages' (whatever you consider those to be) generally don't give you anything.

[0] http://perldoc.perl.org/functions/bless.html