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

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

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

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

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

@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.?

A function may only work with lookupable db ids

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

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

... or conform db/id within fn

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

Typing the result of pull is easy

It’s consistent

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

But that’s the issue right there

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

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

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

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

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?

Well that’s exactly the point

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

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

Longs

you don't have to spec every attribute

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)

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

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

@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

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

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

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

might be related, if you use spec2

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

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