Ah, yea, having a 'data spec' specifically for validation is above and beyond what I meant, which was having your domain contained within a single data structure that can be validated using a number of possible techniques. That validation would be separate from the code that's pulling it apart down the line and actually doing the work on known good inputs.
On Thu, May 26, 2016 at 11:39 AM John Szakmeister <j...@szakmeister.net> wrote: > On Thu, May 26, 2016 at 10:55 AM, Gary Trakhman <gary.trakh...@gmail.com> > wrote: > > I think the idiomatic way to handle this in clojure is to do all your > > validation upfront on a single descriptive data structure, perhaps in a > > single function, then bail early. That has the added advantage of being > > able to report multiple errors, instead of just the first, and is well > > supported by libs like Schema and the new clojure.spec. > > -ENOPARSE. :-) I think you're saying "describe the data you expect > with other data in Clojure", and then use that data to validate the > inputs--hence the reference to Schema. > > I guess the problem I see here is that it's complicated. I really > dumbed things down in my example, but there are a number of properties > of the system that are dynamic: the limits of the axis, what > acceptable values are based on the type of axis, whether the > coordinate system is linear or compass-based, etc. Almost all of this > is determined at runtime when we link up with the equipment, but ends > up driving the kinds of validation we need to do. I'm not sure how > something like Schema would handle this, but... > > I was trying to avoid using Schema, since it's rather large and I have > slow links to worry about (at least for the web side of things). And > I took clojure.spec as something not to be used in production, but to > help with testing--though I see the cross-over. > > **update**: so I went and pulled in Schema, and it's not as bad as I > thought. So perhaps using Schema is more viable than I thought. > > > Maybe if the target of the code is by nature imperative, it would make > this > > more difficult. You could probably abuse exceptions to avoid the > nesting. > > I'm not sure I can say it's imperative by nature--it's my desire to > reduce nesting and the number of edges I have to keep in my brain. I > just haven't found a way that I'm happy to deal with it in a > functional manner. > > As I mentioned, I was trying to avoid exceptions, but you're right--it > may be the only real way forward, but I'm looking for other options > first. :-) > > -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. > -- 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.
