Re: [core.spec] Stricter map validations?

Saw this thread on the REPL, interesting discussion. On Tuesday, October 3, 2017 at 10:57:34 AM UTC-7, Alex Miller wrote: > > > It's not about easier, it's about possible. Open grows, closed breaks. > > I agree with the broad brush, but it's important to listen to this usability feedback

Re: Surprising st/instrument behavior with lazy seqs

Logged this at https://dev.clojure.org/jira/browse/CLJ-2266 with a patch. On Tuesday, November 14, 2017 at 11:26:45 PM UTC-6, Alex Miller wrote: > > > On Tuesday, November 14, 2017 at 11:11:27 PM UTC-6, Didier wrote: >> >> | One option is to use the non-conforming s/every instead of the >>

Re: Surprising st/instrument behavior with lazy seqs

On Tuesday, November 14, 2017 at 11:11:27 PM UTC-6, Didier wrote: > > | One option is to use the non-conforming s/every instead of the > conforming s/coll-of > > Why isn't instrument just validating for all spec? Doesn't conform serve > no purpose here? > Indeed, this could probably be changed

Re: Surprising st/instrument behavior with lazy seqs

| One option is to use the non-conforming s/every instead of the conforming s/coll-of Why isn't instrument just validating for all spec? Doesn't conform serve no purpose here? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group,

Re: Surprising st/instrument behavior with lazy seqs

On Tuesday, November 14, 2017 at 4:16:00 PM UTC-6, Russell Mull wrote: > > > This appears to be happening because the lazy sequence is actually > realized *by* spec when instrumentation is on, but at that point checking > is actually disabled with the st/with-instrument-disabled macro. > > A

Surprising st/instrument behavior with lazy seqs

That's weird, not sure why you get ClassCastException and not the spec error of add1. That said, you can not validate a lazy-seq without realizing it. You can use s/every? on big collections, that will sample x element and validate only those. So its normal for coll-of to realize the lazy-seq,

Re: [core.spec] Stricter map validations?

| 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

Surprising st/instrument behavior with lazy seqs

(apologies for the resend; this didn't reach the web interface the first time around) When I have a function whose arguments I have spec'ed with an fdef, and that function is used in the construction of a lazy seq, it's easy to stumble into situations where the arguments are not actually checked

Re: [core.spec] Stricter map validations?

> 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

Re: [core.spec] Stricter map validations?

> > 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

Re: [ANN] tools.deps.alpha 0.2.167 and cli updates

Oh this looks cool! On Tuesday, October 31, 2017 at 8:21:54 AM UTC-5, Alex Miller wrote: > > tools.deps.alpha 0.2.167 was released on Oct 26th. I have not announced > all interim releases but some of the recent changes include: > >- Overhaul of the provider extension points >- Initial

Re: [core.spec] Stricter map validations?

> > 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 think you're assuming you're validating API endpoints where client and server are

Re: [core.spec] Stricter map validations?

> > Eric does raise an interesting question tho 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

Re: [core.spec] Stricter map validations?

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

Re: [core.spec] Stricter map validations?

Yeah, it seems like if s/keys specs add any keys (required or not) that have specs defined, you're breaking things. Removing the spec definition and removing the key is growth. This explains why people would want things to be stricter at first because it would allow them to relax later. The idea

RE: [core.spec] Stricter map validations?

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

Re: [core.spec] Stricter map validations?

Oh, I see! That makes sense. Thanks! On Tuesday, November 14, 2017 at 10:45:30 AM UTC-6, Seth Verrinder wrote: > > 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

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,

Re: [core.spec] Stricter map validations?

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

Re: [ANN] data.xml 0.2.0-alpha5

2017-11-14 15:33 GMT+01:00 Alex Miller : > Although it looks like that call is intentionally reflective to cover > several possible types. Probably need to solve that with a cond to check > for and hint the actual type at the point of the call. > Yep, see the corresponding

Re: [ANN] data.xml 0.2.0-alpha5

Although it looks like that call is intentionally reflective to cover several possible types. Probably need to solve that with a cond to check for and hint the actual type at the point of the call. On Tuesday, November 14, 2017 at 8:31:48 AM UTC-6, Alex Miller wrote: > > I can replicate that in

Re: [ANN] data.xml 0.2.0-alpha5

I can replicate that in the tupelo tests, but it's coming from enlive, not data.xml. I think enlive needs a type hint on s in this function: https://github.com/cgrand/enlive/blob/master/src/net/cgrand/xml.clj#L85 actual: java.lang.IllegalAccessException: class clojure.lang.Reflector cannot

Re: [ANN] data.xml 0.2.0-alpha5

2017-11-14 4:03 GMT+01:00 Alan Thompson : > I seem to still be getting the JDK 1.9 reflection warning: > > > ~/tupelo > grep data.xml project.clj > [org.clojure/data.xml "0.2.0-alpha5"] > > > lein test > lein test tst.tupelo._bootstrap > >

Re: Map Keywords are functions, why not vector elements?

If you're going to call that for multiple elements of the same vector, it's worth thinking about doing some work upfront so that each look-up is faster: (defn indices [vect] (->> vect (map-indexed vector) (reduce (fn [acc [idx el]] (update acc el (fnil conj [])