Clojurians Log v2
pathom
hey, did you consider using a protocol for the async support so its not coupled to promesa or core.async or whatever and instead is extensible?
something like
(defprotocol IAsyncResult
(on-result [this success-fn error-fn]))
;; conditional dispatch to async if needed
(if (satisfies? IAsyncResult result)
(on-result result handle-success handle-error)
(process-sequentially-somehow result))
;; in a js-promise ns
(extend-protocol IAsyncResult
js/Promise
(on-result [this success error]
(-> this
(.then success)
(.catch error))))
;; in a promesa ns
;; same thing, only importing this ns is optional, API doesn't changesame for core.async and so on
Promesa has such protocols, so you can use them to extend other kinds of futures to conform to it, I did an example on how to make core-async compliant on the docs
do you have any concerns to extending from the promesa side?
I don't like adding promesa as a dependency in my projects when I don't have to
I would have to add something, because of the primitives to run in pathom, I dont want to write a portable future impl between clj and cljs, that's why Promesa (which goes quite close to the core of ComputableFuture on the JVM and Promises on JS)
in contrast, no more dep on core.async
yeah its probably fine. has been a while since I used promesa and it likely corrected some of the stuff they did in the past
just think its a generally good idea to not couple yourself to one specific async impl
yeah, I would totally prefer that, but the differences between environments are big enough that I think its worth in this case (also because Promesa is small, so in this case seems to do just what I need to it)
also already offers the protocols for extensions, so if you want to use core.async, manifold or anything else on your resolvers/mutations, there is the extension point already
what kind of issues you had with promesa in the past?
it used to ship its own promise impl but appears to just use js/Promise now so thats good
guess my main problem with it is gone then
1👍
for core.async there's a cheaper way than what you do in the example: you can just make completablefuture extend the writePort/readPort protocol I think, so core.async can take/put a cf directly, that saves creating a channel.
I might just send a PR for this, I am juggling with too much stuff right now
something like that https://gist.github.com/hiredman/1788aa052f26d127c00a1679656026f0 (not sure the impl on the gist is correct tho)
but by looking at your code I guess its doing the reverse of what I'm doing
in my case I'm making core.async channels compatible with promises, so I can use promesa and read from channels as-if they were promises
while your example would allow a CompletionStage to be read as a channel
hey, did you consider using a protocol for the async support so its not coupled to promesa or core.async or whatever and instead is extensible?
something like
(defprotocol IAsyncResult
(on-result [this success-fn error-fn]))
;; conditional dispatch to async if needed
(if (satisfies? IAsyncResult result)
(on-result result handle-success handle-error)
(process-sequentially-somehow result))
;; in a js-promise ns
(extend-protocol IAsyncResult
js/Promise
(on-result [this success error]
(-> this
(.then success)
(.catch error))))
;; in a promesa ns
;; same thing, only importing this ns is optional, API doesn't changesame for core.async and so on
Promesa has such protocols, so you can use them to extend other kinds of futures to conform to it, I did an example on how to make core-async compliant on the docs
do you have any concerns to extending from the promesa side?
I don't like adding promesa as a dependency in my projects when I don't have to
I would have to add something, because of the primitives to run in pathom, I dont want to write a portable future impl between clj and cljs, that's why Promesa (which goes quite close to the core of ComputableFuture on the JVM and Promises on JS)
in contrast, no more dep on core.async
yeah its probably fine. has been a while since I used promesa and it likely corrected some of the stuff they did in the past
just think its a generally good idea to not couple yourself to one specific async impl
yeah, I would totally prefer that, but the differences between environments are big enough that I think its worth in this case (also because Promesa is small, so in this case seems to do just what I need to it)
also already offers the protocols for extensions, so if you want to use core.async, manifold or anything else on your resolvers/mutations, there is the extension point already
what kind of issues you had with promesa in the past?
it used to ship its own promise impl but appears to just use js/Promise now so thats good
guess my main problem with it is gone then
1👍
Hey all, is there a recommended way to compose transforms? It looks like currently only one function is accepted so my first though is to just reach for comp
I was thinking about that yesterday
the idea I have is to make transport supports vectors, in the same way register does
so you could do as:
::pco/transform [t1 t2 t3]
but before that you can use comp, single param in and out, works fine
for core.async there's a cheaper way than what you do in the example: you can just make completablefuture extend the writePort/readPort protocol I think, so core.async can take/put a cf directly, that saves creating a channel.
I might just send a PR for this, I am juggling with too much stuff right now
something like that https://gist.github.com/hiredman/1788aa052f26d127c00a1679656026f0 (not sure the impl on the gist is correct tho)