Re: Information Hiding

> 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 --~--~-~--~~--

Re: Information Hiding

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 c

Re: Information Hiding

On Mon, Mar 23, 2009 at 10:09 AM, Konrad Hinsen 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 would be advantageous c

Re: Information Hiding

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

Re: Information Hiding

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 wrote: > > I've been thinking quite a bi

Re: Information Hiding

On Mar 23, 7:30 am, Mark Volkmann 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, but I want to under

Re: Information Hiding

On Mon, Mar 23, 2009 at 3:27 AM, Mark Engelberg 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 least be an informa

Re: Information Hiding

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 so

Re: Information Hiding

> Any other tricks or techniques There is defn- 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, se

Re: Information Hiding

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 ot