Avoiding encapsulation doesn't mean that every function needs to act on a
huge global data structure. On the contrary, one of the core ideas of
Clojure is that we should try to reduce incidental interconnections. What
you describe in your example is essentially complexity creep.
Ideally, functions should access only the data they need. For instance, you
might have a function:
(defn available [{:keys [stock reserved]}]
(- stock reserved))
In the function arguments we're deliberately restricting the data down to
two keys. We could also use core.typed to enforce this for us:
(ann available ['{:stock Int, :reserved Int} -> Int])
- James
On 8 May 2015 at 17:29, Brian Craft <craft.br...@gmail.com> wrote:
> 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.
>
--
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.
