On Mar 24, 12:58 pm, Raoul Duke <rao...@gmail.com> wrote: > question: what do people think about the general topic of inheritance? > my take on it so far is that inheritance apparently sounds like a good > idea at first to some folks, but quickly turns into something of a > nightmare if one is actually concerned with keeping a coherent > semantics (so that (a) people can learn it (b) simulate it in their > heads and (c) so you can have tools to check things maybe and (d) > ultimately so the code using it sucks less -- things like LSP and Java > Generics show how fubar it can easily be). so people have come up with > mixins, and then traits. and interfaces. and stuff. > > mainly, i just hope that whatever OO Clojurians finally coalesce > towards doesn't make the same mistakes that have already been made by > plenty of other languages, from old C++ through to new Scala. (not > that i have the Programming Language Theory chops to help much there, > myself.) I'm not a big fan of inheritance; neither am I ardently opposed to it. It's basically an automated facility for copying common code. On the plus side, it's one approach to providing support for the principle of "Don't Repeat Yourself". On the minus side, most systems with inheritance combine the inheritance of behavior with the inheritance of data structure, which are two totally different things. As always, conflating orthogonal concerns leads to gratuitous duplication: you inherit from a class because you want its data layout, but end up writing gratuitous extra code because the inherited behavior is no good to you (or vice versa). Also on the minus side, systems with inheritance encourage you to scatter your API definition over lots of places, which can be an obstacle to maintenance and judicious use. I personally like Haskell's philosophy in this area: there is a facility for defining data layouts, and there is a facility for defining protocols, and they are completely separate. You can define a new data layout without any reference to any behavior. Similarly, you can define a new protocol and the behaviors it supports, without any reference to any particular data layout. You can implement any protocol you like at any time for any data layout you want, without needeing to change the definitions of any data layouts. And, conversely, you can add and extend data layouts any time you want, without affecting existing implementations of behavior. A Clojure system with a similar philosophy might consist of two facilities: a facility for defining record types with named fields, with record-extension that enables you to say "this record is that other record over there plus these fields"; and a facility for defining multifunctions that dispatch on some computable characteristic of their arguments. Clojure's built-in defstruct provides a way to specify record types, but not to extend them. Konrad Hinsen is experimenting with a typesystem that provides another way to define data layouts. Clojure's built-in MultiFns provide one way to define functions that dispatch on computable characteristics of their arguments. I'm experimenting with implementing CLOS-style generic functions, which is another approach (I have found Clojure MultiFns awkward to use thus far, especially when trying to design extensible APIs around them; client code has to know too much about the implementation details of MultiFns--e.g. you have to know when and how to hand-tweak dispatching for the particular MultiFns you are given). --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
