This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-07-12
Channels
- # announcements (2)
- # babashka (22)
- # babashka-sci-dev (15)
- # beginners (62)
- # calva (2)
- # cider (8)
- # clj-kondo (33)
- # clojure (52)
- # clojure-europe (46)
- # clojure-losangeles (1)
- # clojure-norway (5)
- # clojure-spec (7)
- # clojurescript (31)
- # conjure (20)
- # data-science (4)
- # datalevin (16)
- # fulcro (28)
- # hyperfiddle (71)
- # introduce-yourself (3)
- # lsp (50)
- # off-topic (16)
- # polylith (8)
- # portal (3)
- # practicalli (1)
- # reitit (1)
- # releases (2)
- # tools-build (22)
- # vim (8)
- # xtdb (17)
Hi! Looking for an old blog post. Title something like “Lost in a forest of maps, all looking alike”. It was about working without structure with maps and data in Clojure, not properly encapsulating tings, and ending up with a very confusing code base. Anyone remember the text?
Just in case it might be useful, there's also a podcast episode from Eric that on the surface kinda argues the opposite: https://ericnormand.me/podcast/why-getters-and-setters-are-terrible
When I asked Eric about it in an email, his answer was:
> The two things aren't in conflict. Getters and setters are tools. We should use them when needed.
>
> In the Java getters and setters example, as a layer of indirection, they usually aren't useful. They might as well make the fields public and access the field alone. However, people put getters and setters in by default. Furthermore, the programmers are ignoring the strength of the OO paradigm, which is to build objects which maintain consistent relationships between their fields. If you are allowed to set them, they can't maintain the relationship.
>
> In the Clojure nested maps example, Clojure gives you getters and setters for free (with get
and assoc
). You can get very far with them. However, if you find you are in a real mess, like I explain in the talk, where you've got maps you can't remember the keys of, or what data is nested, etc, a bit of abstraction is called for. Explicit domain-specific getters and setters (or updaters) might help.
love this part: > However, if you find you are in a real mess, like I explain in the talk, where you’ve got maps you can’t remember the keys of, or what data is nested, etc, a bit of abstraction is called for. Explicit domain-specific getters and setters (or updaters) might help.
not sure if he references it in the talk/podcast, but this seems to be what the whole concept of Lenses/Optics is trying to solve
> Lenses/Optics is trying to solve Or Pathom, for me, in multiple cases 🙂