Thanks Alex.
Yep, I think Prismatic's schema is going to be invaluable for making the
data structure less opaque and providing the comfort that I have lost from
the lack of a rigorous and extensive strict type system (carefully avoiding
the use of "strong", "lose", "static" and "dynamic" :)).
On Tuesday, April 22, 2014 4:26:59 PM UTC+1, Alex Miller wrote:
>
> Clojure is designed to make your data accessible generically without
> getters/setters or other custom APIs so I would encourage direct access via
> keywords over accessor fns.
>
> One consequence of this is that fns using a data structure have a direct
> coupling to the structure of the data. I prefer to see this as (usually) a
> feature. Accessor functions allow you to create a point of indirection and
> I have used that occasionally in very narrow circumstances where I did not
> want to commit to a data structure. However, I think this is the exception
> rather than the rule. defrecord (or add-ons like Prismatic's schema
> library) can formalize the contents of your entities and provide
> documentation and validation where and how you need it.
>
> On Tuesday, April 22, 2014 4:43:53 AM UTC-5, Colin Yates wrote:
>>
>> (This has been discussed before but as this is fairly subjective I am
>> interested in whether people's opinion has changed)
>>
>> What are people's experiences around using keywords or defined accessors
>> for navigating data structures in Clojure (assuming the use of maps)? Do
>> people prefer using "raw" keywords or do people define accessors.
>>
>> For example, given {:my-property 10} would people inline "my-property" or
>> define a (defn my-property [m] (:my-property m))? If you use keywords then
>> do you alias them (i.e. (def my-property :my-property)?
>>
>> My experience is that accessors become painful and restrictive really
>> quickly (navigating nested maps for example) so keywords are the way to go.
>> I tend to have a domain.clj which documents my domain and defines all the
>> important abstractions (i.e. (def my-property :my-property). I find this
>> very useful, combined with marginalia for documentation purposes. It also
>> offers some aid in refactoring as multiple abstractions might resolve to
>> the same keyword (i.e. value-group and bracket-group might resolve to
>> :group).
>>
>> But, to be blunt, it can be a little cumbersome. I also refer :as the
>> namespace, so instead of (get-in m [:a :b]) it is (get-in m [dom/a dom/b]).
>>
>> What are your thoughts (and any other hints/tips for maintaining large
>> Clojure code bases?)
>>
>
--
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.
