I would generally handle this sort of encapsulation at the namespace level.
Put (create-woobly) and (add-job) and all the other woobly-related functions into a woobly namespace. Also add any functions that access info from a woobly bag-o-state, or mutate a woobly to make a woobly-with-extras. Functions that might dangerously expose internals of a woobly can be made private, or possibly you can just document them in a way to warn folks away from "bad" behaviour. While external users of (woobly/create-woobly) can in theory dig into the internals of the woobly "object", but it should be relatively obvious that this isn't a good idea. I'd defer making protocols until you actually need polymorphism. - Korny On 10 May 2013 03:03, Colin Yates <colin.ya...@gmail.com> wrote: > Thanks for all the helpful responses. > > One reason I want to hide the internals is that I don't want people to add > jobs directly to the queue. (add-job) will put a map containing the > provided function onto the queue. Not really relevant, but this is so that > I can track queue timings that I can later on use to determine how much > capacity the system can handle. > > I am nervous as well about "expose internals but trust people to do the > right thing" because in this case, if I was a consumer and saw that queue, > particularly given the emphasis about data being the contract etc. then why > would I think *not* to use it. > > I do appreciate the point about not needlessly obfuscating information - > this is a slightly different case. > > Sounds like in this case, either reify is the way to go or maybe return a > bad of data but have this stuff in an 'internal' map (i.e. {:internal > {:queue...}}) > > Thanks a bunch - really helpful. > > > On 9 May 2013 17:30, James Reeves <ja...@booleanknot.com> wrote: > >> On 9 May 2013 17:07, Colin Yates <colin.ya...@gmail.com> wrote: >> >>> The part I am struggling with is how to create a Woobly without exposing >>> its internals. >>> >> >> To what end? What's the benefit? >> >> If you take a look at some internal data structures Clojure uses, like >> zippers or protocols, you'll notice that they're just maps. In general >> there's no need to try and obfuscate data to stop people from diving into >> the internals; just don't provide a public API for the internal parts and >> people will get the hint. >> >> - James >> >> -- >> -- >> 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 a topic in the >> Google Groups "Clojure" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/clojure/D2OBBPTxGfY/unsubscribe?hl=en. >> To unsubscribe from this group and all its topics, send an email to >> clojure+unsubscr...@googlegroups.com. >> >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- > -- > 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/groups/opt_out. > > > -- Kornelis Sietsma korny at my surname dot com http://korny.info .fnord { display: none !important; } -- -- 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/groups/opt_out.