I think the suggestions thus far are not ideal. Both protocols and
multimethods provide a way to define a default case. The default case gives
you opportunity to adopt a delegation / component based design.

(defprotocol IFlightOrgan
  (flight-organ [this]))

(defprotocol IFlight
  (can-fly? [this])
  (fly [this] [this body]))

(extend-type Object
  IFlight
  (can-fly? [this]
    (satisfies? IFlightOrgan this))
  (fly
    ([this]
       (fly (flight-organ this) this))
    ([this body]
       (fly (flight-organ this) body))))

Now any type that provides a flight-organ can fly (note we even handle the
self-sufficient case). How the flight organ is acquired is completely up to
the provider - it could be a field or it could done via map lookup (if you
need the type to be the aggregate of many components).

This paper is really worth reading, "Organizing Programs Without Classes"
http://cs.au.dk/~hosc/local/LaSC-4-3-pp223-242.pdf

David

On Sun, Feb 5, 2012 at 4:15 PM, Razvan Rotaru <razvan.rot...@gmail.com>wrote:

> Hi,
>
> I found some posts about this topic, but they did not clarify things
> in my head well enough, so I have to start my own... :)
>
> I'm basically craving for multiple inheritance or mixins, at least
> with my current way of thinking. I haven't really gone deep enough
> with multimethods or protocols, so I might be a little off track by
> looking for multiple inheritance.
>
> Let's take an example:
>
> I want to implement some gui widgets, so there's a main method
> "render" which draws the widget on the screen. I want to have two
> types:
>
> - Textfield
> - Datetimepicker
>
> Each can be "mixed" with the Label widget, so that we have:
>
> - LabelledTextfield
> - LabelledDatetimepicker
>
> So, two challenges occur:
> 1/ the render method for Label needs to call the render method for
> it's "mixed" widget (either Textfield or Datetimepicker) - let's
> assume that labels are rendered "around" the actual widget, so that we
> have a simple way to mix the implementations of render method
> 2/ the Label widget comes with its own data (the label text)
>
> For the second thing, I think it will work with defrecords, since the
> label can be a map entry which can be stored in the actual widget,
> even if it's not mixed with Label. I still want to point this out in
> case there are other ways of achieving this.
>
> How can I achieve 1? Are there alternatives for 2?
>
> Thanks for reading,
> Razvan
>
> --
> 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
> Note that posts from new members are moderated - please be patient with
> your first post.
> 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

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
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

Reply via email to