An eval requirement will still be an impediment to me but it's good to hear that things are still being worked on. I'm happy to do any early testing of proposed approaches and give feedback.
Thanks for letting me know -- keep us posted! -Aaron On Wednesday, December 13, 2017 at 10:45:56 PM UTC-5, Alex Miller wrote: > > Another possible option is using spec specs (CLJ-2112) to unform from a > spec data form to a spec (but that would still need to be evaluated) - > still very much a wip. > > However, we are working on a spec update that will target some of this, so > stay tuned for that. > > > > On Wednesday, December 13, 2017 at 5:14:34 PM UTC-6, Aaron Brooks wrote: >> >> I've found in several projects that I want to have families of specs that >> have some shared structure but some differing structure. >> >> Consider a case where I have some, possibly nested, structure which in >> some cases will have some type of place-holder values which will later be >> replaced with actual values. I don't want a spec to have an 's/or at each >> position that could have a place-holder since I expect the structure to be >> populated with only place-holder values or only resolved values and want to >> exclude a mix. >> >> Neither do I want to maintain two versions of the spec by hand. Some of >> the structure is complex and would be a pain to keep the two in sync. >> >> This appears to leave two choices. >> >> I'd like to describe the spec and then walk the spec, generating the >> other spec instance. Due to the macro-y nature of spec, I think this means >> eval which makes this not cljc/cljs friendly for self-hosted ClojureScript. >> >> The alternative seems to be to build a set of macros that will generate >> both forms of the specs. This is awkward since it requires the full spec to >> be defined within the macro form and winds up being much more complex than >> a walk-and-transform of one spec into another. >> >> What is the best practice for generating specs like this? Am I missing >> something? >> >> I'm afraid the current macro-y, non-data-y implementation of >> clojure.spec.alpha really renders certain usage patterns (say specs that >> are derived from meta-specs) very awkward or inaccessible. I know spec >> needs to capture symbols and forms but wish that was a ease interface on >> top of a data oriented implementation that was first-class. >> >> Let me know if I'm missing something in how I'm thinking about this or >> what my available options are. >> >> Thanks! >> >> -Aaron >> > -- 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.
