| I think you're assuming you're validating API endpoints where client and server are tightly coupled. I can imagine a microservices system where some services put maps on a queue and others consume them. The consumers should allow keys they don't understand. They and also need to validate that the keys they need are there and of the right shape.
That use case sounds more like the exception then the rule to me. I still think its valid, and for that I recognise there should be a way to have a spec which allows any key and requires specific ones. Now that I've listened to everyone, I see that there might be many things needed by different people, and its not clear if all should be provided by spec directly. Mostly I can see wanting: A. To spec a map in which you expect the keys to have a registered spec. B. To spec a map in which you don't expect the keys to have a registered spec. 1. To spec a map in which the keys should be closed to only the req and opt keys that are defined. 2. To spec a map in which the keys should be open to what is defined, but where certain keys are required and others reserved as optional. Where we want to be able to mix and match A,B with 1,2. I see a safe default being A,1. Though I'd be okay with A,2. I think B is the bigger issue not to have as default, and is less intuitive. It's prone to typos and forgetting to add the spec or require the proper namespace, etc. My conclusion: I think s/keys is a funny part of spec, because compared to all other provided speccing tool, this one is really just syntax sugar for convenience. Yet it makes sense, because it is just so damn convenient. But for a lot of people like me, its convenient in a surprising way, which leans towards compatibility instead of correctness and security. And most baffling, trying to spec a map in a correct, secure and convenient way is not possible, at least not with the same convenience. So I'd say if there was just also convenient s/closed-keys and s/specified-keys and s/specified-closed-keys everyone would be happy, and it would also be more explicit what distinction exist between all 4. I'd probably always reach first for s/specified-closed-keys, and relax if I need too only, but all least everyone would have what they want and could chose for themselves. -- 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.
