Fork me on GitHub
#clojure-spec
<
2019-02-28
>
drone00:02:45

maybe spec is trying to do too much. it’s acting as a specification for: contracts, test value generators, and data coercions

drone00:02:16

when you make use of chaining predicates to solve your problem, you can express the contract you’d like. but at the cost of support for the other areas

drone00:02:09

I use spec only for contracts, so hadn’t experienced the pain

drone00:02:26

it’s ironic that the argument for spec over any kind of static type system leans significantly on expressiveness. but with that expressiveness (i.e., arbitrary predicates) comes tradeoffs that make difficult to accomplish some of the other goals of spec

misha02:02:35

@lilactown I think your :user/super-cool-program (or something as specific as such fields combination) should be just predicate with a custom generator.

misha02:02:41

@favila what is the downside (and is there any?) of always having conformed datomic's :db/id tagged, like [:lookup-ref [:user/name "foo"]] or [:perm-int 12345]. Where do you actually need to constantly check against e.g. not-a-temp-id, so you'd be forced to come up with funky qualifying s/and, etc.?

favila02:02:16

A function may only work with lookupable db ids

misha02:02:18

ofc, I'd love to always get conformed {:db/id 1234} out of queries/pulls. But is it a high price?

misha02:02:02

that means you'd need to conform first, and have function working with conformed map, right?

misha02:02:21

... or conform db/id within fn

misha02:02:16

do you actually have an example of such fn? can't think of one from the top of my head

favila02:02:19

Typing the result of pull is easy

favila02:02:25

It’s consistent

favila02:02:17

Typing a map intended for a tx is harder because you’re typing a particular instance of a dsl

favila02:02:36

But that’s the issue right there

misha02:02:47

how is it different, given you specced db/id as s/or? oh wait. db/refs -_-

favila02:02:08

:db/id or :my/ref-attr has different types

misha02:02:37

yeah, db/refs are pain. even in pull btw.

favila02:02:39

Depending on whether it is produced by a pull or embedded in the map of a TX Map dsl

misha02:02:45

yeah, does this mean entire app's specs will know about datomic (app uses datomic and the :user/friends is a :db.type/ref)? or is there another way?

favila02:02:43

Well that’s exactly the point

favila02:02:28

Some functions deal with :db/id (just to pick one attr) in a pull result context

favila02:02:51

I those causes they want to assert such values passing through them are always Kong’s

Alex Miller (Clojure team)02:02:01

you don't have to spec every attribute

favila02:02:15

In other map contexts or parts of the app the same attr means something different (eg it’s meant for a tx later, or it can be anything d/entid can resolve)

misha02:02:03

Alex, true. I need to think through what I will not get if I omit :db.type/refs from spec registry, e.g. generative testing or validation -wise

Josip Gracin08:02:42

Is there any reason the following two definitions would not be equivalent? I'm having some problems with the one using partial.

borkdude08:02:59

@josip.gracin Works for me:

user => (defprotocol Foo
  (foo [this]))
Foo
user=> (extend-type java.lang.Long Foo (foo [this] this))
nil
user=> (s/valid? :n/k 1)
false
user=> (satisfies? Foo 1)
true
user=> (s/valid? :n/k 1)
false
user=> (s/def :n/k (partial satisfies? Foo))
:n/k
user=> (s/valid? :n/k 1)
true

borkdude08:02:51

it could be that after you change the protocol, you have to re-define the spec. to be sure, just reload your program entirely

Josip Gracin08:02:52

thanks! I just needed a sanity check before I go further into debugging. I have a situation where those two behave differently.

misha10:02:39

@josip.gracin there are some nuances between the 2 in spec2: read ~10-20msgs starting from https://clojurians.slack.com/archives/C1B1BB2Q3/p1551208861176100

misha10:02:35

might be related, if you use spec2

Josip Gracin10:02:44

@misha thanks! I'm using spec1 for this.

borkdude10:02:19

spec2 isn’t really finished, so not recommended to use yet I think