Hi guys, when you talk about encapsulation do you mean using defrecords + protocols ? In this case, we are talking of choosing defrecords instead of plain functions. Maybe it would be better if we talk too about the drawbacks of this choice. For example, can we compose or extend protocol functions (I mean to extend existent component protocol functions).
In some occasion, I wanted to use juxt/bolt [(formerly juxt/cylon) security component based system] in GoogleAppEngine but juxt/bolt uses http-kit and GAE dont' let you use this lib dependency. So at last I had to fork juxt/bolt to switch the http client library for plain java.net classes. So, I wonder myself which are the limits of reusability in component pattern. El viernes, 8 de mayo de 2015, 18:29:50 (UTC+2), Brian Craft escribió: > > Talk on the list about encapsulation usually comes back to some variation > of "you don't need it when you have immutable data structures". But in the > long term I'm finding the problem of working w/o encapsulation is not the > danger of data being mutated under you. Rather, it's the danger of all the > module boundaries blurring over time, leading to the big ball of mud: a > very fragile code base where everything depends on everything else. > > E.g. if you model your application with a plain data structure which you > pass around to different modules, each concerned with a small part of that > data structure, the tendency over time is for every module to become > concerned with every part of that data structure. Then you have no > separation, nothing is reusable, and the code is very fragile. > > How do you avoid this, practically? In OO it would be enforced with > encapsulation, so the next developer (which might be me, six months later) > trying to fix a bug, or add a feature, knows "Oh, I shouldn't peek in here: > this module isn't supposed to depend on that piece of data". > -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
