I've written a library that tries to solve this, instead of making conforms that do coercion, it uses the spec and a separated registry to conform the value (similar to what spec does to find the generators for a given spec). You can find the library at: https://github.com/wilkerlucio/spec-coerce. This way you don't complect the conformance with coercion.
On Thursday, February 22, 2018 at 11:19:35 PM UTC-3, Didier wrote: > > Map specs are about attribute aggregation, not about types. >> > > I understand the design philosophy. I think that's great. What I meant I > guess is that it would be nice to also have a declarative way to relate > Types to Specs, for when Specs fall short of types. Then you'd have the > best of both world. Specs where Types fall shorts, and Types where Specs > fall shorts. > > You can effectively do this already. When you have s/keys maps which are >> sets of attributes, you can simply combine sets (base and extensions) using >> s/merge. Or when needing more polymorphism, s/multi-spec. >> > > I guess I'm talking about Types as in primitive types included. So if I > create a String type, I can describe what is the set of values for the type > using a spec. Similarly, I now know that the Type and the Spec used to > describe its possible set of values are equivalent. So I now know the > relationship between them. > > The real reason I want this is so that I can auto-generate client code in > different languages for my Specs. > > I'm thinking of it as a more generic Swagger OpenAPI specification. > > Maybe what I'm thinking off doesn't make sense, its all kind of at the > blurry idea phase in my head. > > Currently, I manually have an equivalent set of Java Classes which > correspond to the specs of my data which gets shared between Java and > Clojure systems. And I manually have functions which converts a piece of > data from a given Spec, into its Java equivalent representation and back. > I've been thinking about how I could have the equivalent Java classes be > auto-generated, as well as the conversion be automatic. The biggest > challenge is knowing what Java types would a given Spec map too. So I > thought if I my spec could have a mapping on them too, then it wouldn't be > too hard. When you write your Spec, you could associate it with an > enclosing Type, and then from the Specs I might be able to auto-generate > the Java model classes. > > Anyways, the whole thing is incubating in my head. And I can probably do > it on top of Spec if I really needed too. > > On Wednesday, 21 February 2018 18:47:20 UTC-8, Alex Miller wrote: >> >> >> On Wednesday, February 21, 2018 at 7:34:00 PM UTC-6, Didier wrote: >>> >>> I would actually love it if Spec was extended to have the concept of >>> types. >>> >> >> Map specs are about attribute aggregation, not about types. >> >> https://clojure.org/about/spec#_map_specs_should_be_of_keysets_only >> >> >>> Something where every spec could be tied to a Type, and types could be >>> constructed to have Hierarchies. >>> >> >> You can effectively do this already. When you have s/keys maps which are >> sets of attributes, you can simply combine sets (base and extensions) using >> s/merge. Or when needing more polymorphism, s/multi-spec. >> >> -- 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.
