hey, architects--- I'm trying to design an API, and my first idea isn't compatible with spec. Can anyone suggest alternatives? https://clojurians.slack.com/archives/C1B1BB2Q3/p1523995746000171?thread_ts=1523995746.000171&cid=C1B1BB2Q3

Facts about the domain: - every simplex is a special case of a complex, but there are complexes that are not simplexes - the Java library I'm wrapping understands only integer vertices, so I want to have implementations that map arbitrary non-collection data to integer vertices - users might want to provide their own implementations, to shortcut certain naive approaches that are exponential time

I want to use many specs to add value to the Java library, but the way I've gone about this, I'm trying to spec protocol functions which is not actually possible

There is a suggestion to use wrapper functions --- I only sort of know what that means, but I'll be meditating on it

I would push back on "isn't compatible with spec" spec has a lot of different parts, and some parts don't work well protocol functions

something like (assert (valid? `dim dim)) would likely work

The "wrapper function" thing just means (defn make-frobber [] (let [init-val 123] (Frobber. init-val))) or some such

so the things you'd normally do in a constructor, you do in make-frobber

(... if I understood your 'wrapper' comment correctly)

oh my bad, I thought your reference to wrapper fns were about another conversation in another room...

So, wrt wrapping a protocol fn... Wouldn't that just mean defining a top level function that calls the protocol fn on the object passed in? And then instrument that?

for me, I don’t think that’s worth doing - I would just not spec the protocol functions

it’s ok not to spec everything :)

heh! well, I definitely want to make topological data analysis more accessible, and I supposed that defining invariants at that level would help. however I also have a math-tendency to make things more general than is needed for the problem. Still working on coding with good taste!