I would stop the specing at the boundary of a IDeref. For example you can say "this function takes a integer and returns a instance of IDeref". Digging into the details of that object isn't something I would try to spec. Beyond that I would probably try to write functions that take data and return data. IMO a function that takes data and returns a opaque object is somewhat of an anti-pattern.
On Sat, Oct 29, 2016 at 10:46 PM, Mohammad Sadeq Khoeini <[email protected] > wrote: > Correct. However I'd like to use documentation and generative abilities of > clojure.spec. I could directly deref inside my functions and then > everything would work nicely. However, That would raise efficiency concerns. > > I would say in my case derefing doesn't cause a huge problem, and writing > some spec-creator like =(my.specs/deref ::my-message)= might not be that > bad; But I was seeking some advise from you. How would you spec something > like this? My initial thought is something like this: > > (defn get-messages [& args] ...) > > (s/fdef get-messages > :args ::get-messages-args > :ret (my.specs/deref (my.specs/api-result ::api-message))) > > > On Sunday, October 30, 2016 at 3:10:37 AM UTC+3:30, tbc++ wrote: >> >> Specs are for checking the shape of data. "deferreds" are not data, they >> are opaque objects. So in short the answer is "you can't" or more >> correctly: you may be able to, but shouldn't. >> >> One of the problems with even trying to spec something like IDeref is >> that the very act of observing it may have a side effect. For example: >> (delay (launch-missiles)). The only way you can see if that conforms to >> some spec is by calling `deref` on it which would have the side effect of >> launching some missiles. This sort of thing follows the same advice Clojure >> has had for some time...put data inside IDerefs don't put IDerefs inside >> data. >> >> On Sat, Oct 29, 2016 at 10:38 AM, Mohammad Sadeq Khoeini < >> [email protected]> wrote: >> >>> >>> I'm trying to write a wrapper for telegram api[1]. Responses from the >>> api are either successful, >>> which would then have a `{"ok": true, result: ...}` shape, or error with >>> the shape of `{"ok": false, description: "..."}`. >>> Also, I'm using aleph to call the api. So, the responses are deferreds >>> [2]. >>> >>> Now, I want to write spec for my functions like get-messages, etc. But >>> the problem is I have no clue how I can model something like this. >>> It appears to me that I want to model something like generics of other >>> languages. i.e. IDeref<Message>. But I can't see any straight forward way >>> to do so using clojure.spec. >>> >>> What would you say be the idiomatic approach to model this. >>> >>> >>> [1]: https://core.telegram.org/bots/api >>> [2]: http://aleph.io/manifold/deferreds.html >>> >>> BR. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to [email protected] >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> [email protected] >>> 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 [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> “One of the main causes of the fall of the Roman Empire was that–lacking >> zero–they had no way to indicate successful termination of their C >> programs.” >> (Robert Firth) >> > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to [email protected] > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > [email protected] > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
