it might be helpful to consider that in the jvm methods are not data,
and the proto function makes the method into concrete data belongs to
the namespace that owns the protocol

On Thu, Nov 21, 2019 at 2:58 PM Justin Smith <noisesm...@gmail.com> wrote:
>
> if you define proto method x, it belongs to the protocol namespace no
> matter where it is called, and calling it as if it belonged to the
> namespace defining the object extending the protocol will and should
> fail
>
> On Thu, Nov 21, 2019 at 1:57 PM Dimitrios Jim Piliouras
> <jimpil1...@gmail.com> wrote:
> >
> > Hi folks,
> >
> > This has me completely stumped - I would massively appreciate a helping 
> > hand! Suppose the following simple directory structure:
> >
> >
> > — someProject.impl.{foo.clj, bar.clj,baz.clj}
> > — someProject.proto.clj
> > — someProject.api.clj
> >
> > `proto.clj` contains a single protocol with two methods - let’s call them X 
> > & Y. Each implementation namespace (foo, bar, baz), requires 
> > `[someProject.proto :as proto]`,  extends it to 3 types 
> > (bytes/chars/String), and defines two public fns x & y which delegate to 
> > `proto/X` & `proto/Y` respectively. Everything is good so far. I can fire 
> > up a REPL, load any of the impl  namespaces (foo, bar, baz), call the 
> > corresponding x or y fn and get the right result.
> >
> > Now, I want to provide a unified API so that the caller doesn’t need to 
> > (potentially) require 3 namespaces. Hence the `someProject.api` ns, which 
> > contains require clauses for all impl namespaces + two multi-methods 
> > `X-with` & `Y-with` with 3 implementations (`defmethod`) each. Each 
> > implementation delegates to the x or y fn in the right impl namespace. In 
> > other words,  `X-with :foo` calls `(foo/x)`, `X-with :bar` calls `(bar/x)` 
> > etc etc. Remember, that calling x or y inside any impl namespace works 
> > correctly, so all I’m doing here is providing a multi-method wrapper. 
> > However, things don’t work as I was expecting in this namespace…Loading 
> > `someProject.api` in a fresh REPL and calling  `X-with :foo` bottoms out at 
> > the protocol extension for X in the baz ns, which is the last require 
> > clause in the api namespace.
> >
> > So basically,  the protocol extensions in each impl namespace work fine 
> > when called from their wrapper fn in the namespace they were defined, but 
> > don’t quite work when the same wrapper fn is called from some other 
> > namespace! What am I missing? :(
> >
> > Many thanks in advance…
> > Dimitris
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > 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 clojure+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/clojure/A549FB15-0B12-4E20-9D98-4F5A56330DC4%40gmail.com.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
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 clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAGokn9%2B1ZiFHBzuS_bwSyrx0DsM_ocu7dk844DnU-h5D3b9fzA%40mail.gmail.com.

Reply via email to