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
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.
cloj
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, whethe
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, (= (
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
off
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 wa
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 dat
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
im
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 like
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 "ma
10 matches
Mail list logo