> > I don't think this is necessarily true - you lose granularity in the > example you give because you use an opaque predicate. If the additional > constraint is itself a structured spec, then you do not lose granularity.
True, but since key specs are registered globally, I currently cannot use the same (namespaced) key in multiple parts of "s/and", which rules out a structured spec for this case, I feel. > Spec forms are data and can be conformed against s/form specs (not yet > released) to produce more map-like data suitable for driving data > generation if you like. So this is perfectly ok and something people are > already doing in a bunch of different ways. > [...] > I think if you need to do this in some static way, you are better off > writing the more precise spec (you can use both at different points in your > process, and probably derive the specific parts partly from the generic in > many cases). If you need to do it in a dynamic way, you should use your > specs as data to generate dynamic specs. > If dynamic specs, even for namespaced keys within maps, are a possibility, that would probably address this specific use case quite neatly. (But different specs for the same namespaced key seem to go against one of the main pillars of spec, if I understand it correctly.) As I said, others are already doing this kind of thing with the tools > already in spec. One example that comes to mind is dspec > <https://github.com/lab-79/dspec> - which lets you generate Datomic > schema and specs from an entity model. > While I'll definitely look deeper into dspec I immediately see quite a few calls to `eval` within the codebase. (Same in the spec part of graphql-clj <https://github.com/tendant/graphql-clj>, for example.) This should be something that can be replaced with an "s/form"-based approach, right? Generally, I still really like the idea of having a base spec (e.g. "a variable name is a string") that is globally registered, then allow for context-dependent specialisation akin to "within the given AST, a variable name is either 'a', 'b' or 'c'" that is dynamically generated. But I might be missing the bigger picture since I'm focused on my specific use case, involving lots and lots of dynamically generated, very short-lived, maybe even single-use specs -- 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.
