> I think so too. I'm still finding it hard to come up with a single example of why allowing extra keys to validate would ever be useful even for non-breakage. I can't see how it would break anything. > > I believe the only advantage of allowing extra keys, is to allow partial specs. So say you never had specs, and your API takes a ton of keys, and you start by only speccing half the keys it takes. That's the only use case I could think of.
This is my core concern as well. It seems like it is going to lead to bugs from typos or people expecting specs to have been defined for keywords that weren't defined. It also is incongruous with other parts of spec like s/cat, which does require specs to be registered at check time. I understand there is a technical/implementation detail for the reasons here, but it strikes me as a rough edge that people are likely to continually run into. I've hit it myself already in projects where I spec'ed a map, but didn't have some of the keys spec'ed. I discovered later my mistake, but like Didier, I can't see any time that I would actually want this feature. Because spec's information model is all about namespaced keywords that have a unique unambiguous meaning (at least I think that's the idea?), allowing specing of a map with keywords that don't exist because they may be defined by some other part of the system doesn't make a lot of sense to me. Even if this is a valid use case, it seems like a niche one that would be better served by defining a new function that allows it (perhaps in another library), rather than it being part of the behaviour of the more general purpose s/keys. On Wed, Nov 15, 2017 at 8:53 AM Eric Normand <ericwnorm...@gmail.com> wrote: > If you have an API that cares about ‘a’, ‘b’, and ‘c’ and you later >> specify that ‘d’ is optional and should be an ‘int?’, does that qualify as >> breakage or growth? If clients were sending ‘d’ as a string before but you >> ignored it, it will break those clients. Clients that were not sending ‘d’ >> will not be affected by the change. The old spec – allowing ‘d’ to be >> ‘any?’ essentially – won’t fail on any data that omits ‘d’ or passes it as >> ‘int?’ so it passes your compatibility test. > > > Isn't this precisely why you should use namespaced keywords? >> > > > Yes! Great point. > > That sounds like a great thing to document in your API. Something like: > "all keys in com.xyz namespace are reserved and could be restricted at > any time. Please don't use them." You could send a warning back in your API > if they use any that don't validate. > > Are there any resources that document these best practices? It seems like > Clojure is trying to push us down this road but there's no map yet at the > moment. > > > >> >> >> tirsdag 14. november 2017 19.43.55 UTC+1 skrev Sean Corfield følgende: >> > Eric does raise an interesting question tho’: >>> >>> >>> >>> >>> >> (we actually ran into this at work because a client app was passing a >>> field we didn’t care about and we later decided that was an optional field >>> but couldn’t be an empty string and it broke that client) >>> >> >>> >>> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN >>> An Architect's View -- http://corfield.org/ >>> >>> "If you're not annoying somebody, you're not really alive." >>> -- Margaret Atwood >>> >>> >>> >> *From:* clo...@googlegroups.com <clo...@googlegroups.com> on behalf of >>> Seth Verrinder <set...@gmail.com> >>> *Sent:* Tuesday, November 14, 2017 8:45:30 AM >>> *To:* Clojure >>> *Subject:* Re: [core.spec] Stricter map validations? >>> >>> I took part of the goal to be that specs themselves would remain >>> compatible, so an old set of specs wouldn't start failing on data that >>> conforms to a new but compatible set of specs. That sort of compatibility >>> isn't possible when you go from disallowing something to allowing it. >>> >>> On Tuesday, November 14, 2017 at 10:15:23 AM UTC-6, Eric Normand wrote: >>>> >>>> Hey everybody! >>>> >>>> I'm chiming in after seeing this linked to in The Repl ( >>>> https://therepl.net/). >>>> >>>> On Alex's suggestion, I rewatched Spec-ulation last night. The parts >>>> about negation and evolution are towards the end. I was struck (once again) >>>> by how clearly he picked apart changes. Relaxing a requirement is growth. >>>> And adding requirements is breakage. But it left me with a question: >>>> >>>> Isn't disallowing a key and then allowing it (as optional) growth >>>> (instead of breakage)? All of the old clients are still fine, and new >>>> clients can use the key if they choose. You're relaxing the requirements. >>>> Taking the opposite approach, I require some keys plus allow anything else. >>>> Some clients will inevitably send me something with extra keys, which is >>>> okay, they pass my specs. Later, I add in an optional key with a defined >>>> spec. So I'm now restricting what used to be completely open. Isn't that >>>> breakage? I feel like I'm seeing it exactly opposite as Rich Hickey. He >>>> says if you disallow things, it's forever, because if you need to allow it >>>> later, that's breakage. But there's not enough explanation for me to >>>> understand. It seems like relaxing requirements. I feel like I'm missing >>>> something. In short: why is it forever? >>>> >>>> He does mention is that logic engines don't have negation. Does this >>>> hint that we will want to be using logic engines to reason over our specs? >>>> >>>> Thanks >>>> Eric >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> 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 a topic in the >> Google Groups "Clojure" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/clojure/i8Rz-AnCoa8/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> clojure+unsubscr...@googlegroups.com. >> > >> For more options, visit https://groups.google.com/d/optout. >> > -- > 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. > -- 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.
