I've been thinking quite a bit about the OO side of Clojure the past
couple of days, and trying to figure out how common OO design patterns
would look when ported over to Clojure's way of doing things.
The most obvious thing that others have noted is that you can
effectively simulate a mutable
On Mar 22, 2009, at 10:27 PM, Mark Engelberg wrote:
I've been thinking quite a bit about the OO side of Clojure the past
couple of days, and trying to figure out how common OO design patterns
would look when ported over to Clojure's way of doing things.
The most obvious thing that others
Any other tricks or techniques
There is defn- http://clojure.org/api#toc189 as well as the :private
metadata tag.
Joshua
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Clojure group.
To post to this group, send
Yes, the :private metadata tag is probably the simplest way to make
the whole object private, and then just expose the manipulation
functions. The closure solution is similar in this regard. I guess
the point I failed to convey is that I'm really wondering if there's a
way to effectively make
On Mon, Mar 23, 2009 at 3:27 AM, Mark Engelberg
mark.engelb...@gmail.com wrote:
I suspect that if you use double-colon keywords for the keys, you get
a bit more privacy in the sense that these keys are slightly harder to
accidentally manipulate from other namespaces, so perhaps that could
at
On Mar 23, 7:30 am, Mark Volkmann r.mark.volkm...@gmail.com wrote:
I hadn't run across :: before. How do you determine the namespace of a
keyword? I'd like to see the difference between
(def k1 :a) and (def k2 ::b)
Of course both create vars (k1 and k2) in the user namespace by
default,
You could always build something where setters/getters are auto-magically
created if specified by the constructor macro. And with clojure.contrib.def
you could auto-magically generate private setters/getters.
On Mon, Mar 23, 2009 at 4:27 AM, Mark Engelberg mark.engelb...@gmail.comwrote:
I've
On Mar 23, 2009, at 9:27, Mark Engelberg wrote:
still be essential to the notion of equality). Any other tricks or
techniques for helping to hide or separate out the portions of a data
structure that are meant to be accessed or altered from the portions
that should only be accessed and
On Mon, Mar 23, 2009 at 10:09 AM, Konrad Hinsen
konrad.hin...@laposte.net wrote:
You seem to envisage exposing some aspects of your data structure as
part of the public API and have others reserved for use by
authorized support function. Could you give an example of a
situation where this
On Mar 23, 2009, at 18:20, Mark Engelberg wrote:
standard maps. I guess, loosely speaking, I was envisioning a model
in which seq on a hash map would only traverse the public keys, so
that library functions will work on your objects, without exposing
innards. But perhaps there is no
I was envisioning .. only traverse the public keys
You could provide a function which uses select-keys to return a new map
with only the public* *keys.
This can be seen as an interface into the map held in the ref for read
access, though not for write.
Joshua
11 matches
Mail list logo
