Protocols as a way to improve modularity?
Hi all, in an attempt to find the more idiomatic way to modularize Clojure applications, I was thinking at the role protocols play in such a context. That is, let's say we have a Clojure application with each source file representing a different module (there may obviously be other files with helper/util functions but we don't care about them): what's the idiomatic way to export functions between modules? What about grouping those functions in one or (a few) more protocols per module? By doing so, we have a clear separation of the different modules, as well as a clear identification of the exported functions, but we also have more typing (protocol+record/type definition) and possibly non-polymorphic use of protocols. What are your thoughts about that? Thanks! Cheers! Sergio B. -- Sergio Bossa http://www.linkedin.com/in/sergiob -- 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
Re: Protocols as a way to improve modularity?
Hi Sergio, I think the public/private function options cover your bases here. If you have so many public functions in a namespace, possibly could be a sign to separate them into other namespaces, possibly nested. I certainly think using protocols for this would be an abuse. I've seen a common pattern of putting functions you want used by other namespaces in a group at the bottom of the file. The lack of forward declarations also encourages this. Although you seem to be more interested in C-style explicit exports, I don't think this fits well with anything Clojure currently offers. Thanks, Ambrose On Wed, Aug 31, 2011 at 1:11 AM, Sergio Bossa sergio.bo...@gmail.comwrote: Hi all, in an attempt to find the more idiomatic way to modularize Clojure applications, I was thinking at the role protocols play in such a context. That is, let's say we have a Clojure application with each source file representing a different module (there may obviously be other files with helper/util functions but we don't care about them): what's the idiomatic way to export functions between modules? What about grouping those functions in one or (a few) more protocols per module? By doing so, we have a clear separation of the different modules, as well as a clear identification of the exported functions, but we also have more typing (protocol+record/type definition) and possibly non-polymorphic use of protocols. What are your thoughts about that? Thanks! Cheers! Sergio B. -- Sergio Bossa http://www.linkedin.com/in/sergiob -- 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
Re: Protocols as a way to improve modularity?
On Tue, Aug 30, 2011 at 7:29 PM, Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: I've seen a common pattern of putting functions you want used by other namespaces in a group at the bottom of the file. The lack of forward declarations also encourages this. Yep, I've already done that, just reasoning about alternative solutions. Although you seem to be more interested in C-style explicit exports, I don't think this fits well with anything Clojure currently offers. Nope, I'm more interested in Erlang-style modules and functions exports, but I agree my reasoning could have sounded a bit like that. Thanks for your feedback! Sergio B. -- Sergio Bossa http://www.linkedin.com/in/sergiob -- 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