In this case I would most certainly use multimethods. This is the perfect use case for them.
If you want your views themselves to have certain forms, you may consider applying protocols there. Paul On Oct 15, 8:57 am, Laurent PETIT <laurent.pe...@gmail.com> wrote: > 2010/10/15 K. <kotot...@gmail.com> > > > > "Stop!". When I read this, my mind cries "Alert! potential > > java-in-clojure > > > code here !". > > > Sorry I didn't want to frighten you with the words "MVC" and "Clojure" > > in the same sentence :-). > > However, I think it's just the right approach to separate the > > presentation from the logic. > > I didn't say the contrary. > > > > > I may be wrong and then would be > > interested to hear of different designs which preserve this > > separation. > > > clojure promotes a generic approach to data management. Writing a > > protocol > > > for each piece of data to exchange between parts of the app should warn > > you > > > something is wrong ... (or will quickly become "as" painful as writing > > > idiomatic java) > > > Not a protocol for each piece of data but a protocol for all data. > > Like: > > > (defprotocol View > > (display-banana [this banana]) > > (display-melon [this melon])) > > > etc. Is it worse than having the equivalent functions? It allows me to > > switch the particular implementation without changing the listeners' > > code. > > Just out of my head (disclaimer: please understand I've no formal theory > behind what I'm writing, it's just remarks written in reactive mode, from > the inputs you give to me) : > > what about forgetting about protocols for a minute ? protocol lock you down > in "single dispatch based on type" way of thinking. > > If your protocol functions generally look like : display that data on this > view, then why not leverage multimethods and double dispatch ? > > (defmulti display type) > > and then it's super easy to dispatch your code throughout the namespaces: > > (defmethod display [ViewClass ::banana] [v b] ...) > (defmethod display [ViewClass ::melon] [v m] ...) > > ? > > > > > > Is it too late to challenge the architecture ? > > No. It's never too late ;) > > > > To help you, we would have to know more about your problem ... > > > Ok then just see the application like a specialized editor: you can > > create and open documents, make modifications to them, get help from > > the application to build and parts to your document. Documents are > > represented and edited graphically with Swing. > > > What design would you suggest? > > > -- > > 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<clojure%2bunsubscr...@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
