Isn't this precisely why you should use namespaced keywords? tirsdag 14. november 2017 19.43.55 UTC+1 skrev Sean Corfield følgende: > > Eric does raise an interesting question tho’: > > > > 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. > > > > (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 <javascript:> <clo...@googlegroups.com > <javascript:>> on behalf of Seth Verrinder <set...@gmail.com <javascript:> > > > *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 <javascript:> > 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 <javascript:> > 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 <javascript:>. > 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.
