On Thu, May 26, 2016 at 2:12 PM, Timothy Baldridge <tbaldri...@gmail.com> wrote: > I would suggest reviewing your data model a bit. One of the problems you > are experiencing is that you are overloading the inputs to your function. > And since they are overloaded you have to create a state machine of sorts to > parse out if the data is valid. Another approach is to use namespaced keys > in a map then dispatching on the contents of the map. This removes a lot of > ambiguity in the code.
Can you describe what you mean a little more? I think what you're trying to say it that I should somehow separate switched axes from variable axes, etc., despite that the same data is present in both--just with slightly different semantics. The problem I see there is then I have to somehow figure out which version to grab from the map. If I'm following correctly, you're perhaps suggesting that I pull the type information higher into the data model so I can use it to know which version to grab out of the map? If that's the though process, it seems to me that it's cluttering things rather than making it better--at least from my ability to understand what the data model is actually saying. Having the type grouped under the axis seems more coherent to me. I've probably misunderstood what you're saying though, so an example of what you mean would be really helpful. I'm certain that you're telling me something profound, but I'm just not parsing it out. :-) > Then you can use something like clojure.spec to validate your data: > > (s/def :pos.switch/value #{0 90}) > (s/def :pos.slider/value (set (range 90))) Is there a way to cope with 0 and 90 actually being variable? What I mean is that I don't know what the valid range is until I talk with the back end equipment. So I can't say at compile time what the valid range will be. I took that bit out of my example because I felt it was making things too complex to be useful. > (s/def :switch/change (s/or :nil nil? > :switch (s/keys :req [:pos.switch/value]) > :slider (s/keys :req [:pos.slider/value]))) > > (s/valid? :switch/change {:pos.switch/value 42}) ; => false > (s/valid? :switch/change {:pos.slider/value 42}) ; => true > (s/conform :switch/change {:pos.switch/value 0}) ; => [:switch > {:pos.switch/value 0}] > (s/conform :switch/change nil) ; => > [:nil nil] > (s/conform :switch/change {:pos.slider/dual 0}) ; => > :clojure.spec/invalid > > (s/exercise :switch/change) ; => Generates > 10 example data sets > > And as you see from this example, you can use specs to dispatch, validate > and even generate test data for your application. This is definitely interesting, though I thought spec was geared more towards testing and less towards runtime validation. Well, now that I say that, I guess what was said is that spec wasn't meant to be enabled for everything all the time... you call out the bits you want to do at runtime. It's probably still too new for me to use though, especially since I'm currently using ClojureScript and clojure.spec isn't available there yet. But definitely good to know about. Thank you for the example! -John -- 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/d/optout.