It sounds like you're building an API to provide documentation, but instead
why not just document the data structure directly?
Once you have your data structure design, add functions for non-trivial
tasks. So something like red? seems a little too trivial and specific.
The raw s-expression, (=
Thanks Ryan and James - that gives me a few more ideas on how to think
about things. Hopefully some of the links Ryan posted will clarify things
for me also.
Ryan - yes my question about namespaces was to do with understanding the
ideal granularity of namespaces. And more specifically,
Most Clojure libraries I've seen only give you a handful of namespaces. I
would expect a moderately large Clojure library to expose, say, half a
dozen at most. Remember that Clojure has no concept of star imports, even
for Java classes, and imports will generally be qualified somehow (e.g.
This answer says everything I would want to say better than I would say it.
Second!
Alex
On Wednesday, June 25, 2014 9:12:01 PM UTC-5, Ryan Schmitt wrote:
In object-oriented programming, encapsulation is always and everywhere
regarded as a highly significant design virtue, but the Clojure
I've only recently started real clojure development, so very much still
learning what styles work and what don't. I have a question about naming
attribute getters...
Suppose I want to model fruit entities. I will use a hash-map to
represent the data for each such entity, and will defn a make
I'm curious about this stuff too. (I'm very new to Clojure.)
I wouldn't be surprised if the general sentiment is: “Don't.”
The argument goes along these lines: By encapsulating, you have introduced a
tiny new little API that clients need to learn the semantics of. Additionally,
that API is
In object-oriented programming, encapsulation is always and everywhere
regarded as a highly significant design virtue, but the Clojure people have
a bit of a different assessment, particularly when it comes to information.
In one talk, Rich Hickey pointed out that encapsulation is for hiding
OOP places a strong emphasis on information hiding, particularly by
wrapping data structures in APIs. Developers with a strong background in
OOP tend to try to replicate this style of programming in Clojure.
However, idiomatic Clojure emphasises exactly the opposite of this. In
Clojure, a bare
Thanks Ryan, Mike and James for your comments and info. Ryan I will follow
up the links you posted.
In the meantime, a request for some clarification...
I have read / watched clojure stuff along these lines... ie that data
hiding (in an immutable data context) is bad. I thought my approach
The question of how to specify the shape of your data is an important
one, and I think one of the contributions of Clojure is the way it isolates
that problem, instead of complecting it with object-oriented design or
static type checking. You might look at Prismatic Schema, a library that
10 matches
Mail list logo
