Hi All, I have a library that provides a DSL to build a composite hierarchy of UI objects for a server-side Web framework (https://github.com/wizardpb/functional-vaadin). RIght now, I have a whole bunch of custom code that checks the validity of arguments passed to the builder functions, and I'm seeing that I could use spec to radically improve the readability and maintainability of that code.
However, it seems to me that spec is mostly oriented to checking syntax and basic content, and not so much towards complex semantics relating different parts of a data form. For instance, in my DSL, the arguments can be a set of constructor arguments for the underlying Java object, and/or a Map with keys and values corresponding to setters on that object. This means that argument correctness depends on the object being constructed, which defines the ctor argument types and specific combinations of map keys and values. However, the syntax for these is uniform, which implies that a single spec could be used to check the syntax of the call. It would be possible to augment this basic form with additional semantic checking, probably using the spec regex '&' operator, but I'm wondering what the trade-offs are here. At one extreme I could have a single spec that checks syntax (and extracts the different parts using destructuring - very useful), and a bunch of custom code that checks the more complex semantics, OR a set of custom specs, probably one for each different class I want to build an instance of (possibly generated automatically from a base and type specific parts) My question is: where's the sweet spot between these two extremes - or is there another approach entirely? Any ideas most welcome! -- 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.