Hi James - thanks for your response. I am still trying to wrap my head around this as I cannot agree.
To re-frame, woobly allows you to add a job. The internal implementation of this is that it is decorates that job and puts the *decorated job* onto an internal LBQ. The implementation also depends upon being the only user of that LBQ as well. It is critical that jobs are added using the 'add-job' function. I try and write software that is 'easy to do the right thing, hard to do the wrong thing', and exposing the LBQ makes it trivial to do the wrong thing. Indeed - if I was using the woobly library (I could just say 'scheduler' right? :)) why wouldn't I think 'hey, I've got the LBQ, that is probably how I enter the pipeline' and 'great, now I can dequeue my jobs by calling .clear' etc. Documentation - sure, but documentation will never win a war when it is fighting the 'I know you can do this in the code but don't' fight. The 'bad thing' is that I have exposed too much. And please don't think I am making the 'code should stop bad programmers doing the wrong thing' argument, I'm not (been there, lost). I just know that if I released a scheduler library and the main construct was a map containing a LBQ (or in fact any sequence) then I would be inundated with a bunch of 'I did X to the queue and it broke'.... Is it really 'good Clojure' to expose internals which allow a user to easily and trivially break things? Please don't think I am nit-picking or splitting hairs, I genuinely want to improve my Clojure intuition. On 9 May 2013 21:05, James Reeves <ja...@booleanknot.com> wrote: > On 9 May 2013 18:03, Colin Yates <colin.ya...@gmail.com> wrote: > >> 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. >> > > If this were a problem in general I think we'd find more people poking at > the internals of protocols, but I've never seen that happen. > > You could use namespaced keywords, like :woobly.internal/queue, to give > people more of a hint that the data shouldn't be used without the API, but > I really think you're borrowing trouble with this. > > Encapsulation is like inheritance, in that it's one of those ideas that's > nice on paper, but ultimately not very useful in practise. > > - 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.
