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

Reply via email to