On 12/12/12 17:37, Mark Engelberg wrote:
Yes and no. That's basically what I'm trying to do, but I only have a
handful of concrete implementations to choose from, so I don't mind
writing a hard-coded cond that chooses between them based on some sort
of keyword that the user passes in. So the reflection aspect of this
is not what interests me.
aaa ok...I see. Well, your core ns certainly needs access to the
implementation ns if you are going to use a plain cond.
My problem is that I can't figure out how to put the implementations
in different namespaces without introducing circular dependencies.
The implementations need the core in order to implement the protocol.
The core needs the implementation namespaces in order to provide a
general constructor that can build all the concrete implementations.
Does the use of reflection solve the circular dependency problem? I
don't see how it would.
Yes it would...You're using reflection so no need to :use or :require
the namespaces any more.
Point your browser here if you're not following:
https://github.com/jimpil/Clondie24/blob/master/src/Clondie24/lib/util.clj
this namespace depends on nothing (apart from clojure.pprint). However
all the namespaces in games (the concrete implementations) depend on it.
I can easily create a ChessPiece from within my chess ns using the
record-factory in util.clj (even though util.clj knows nothing about
games). However, as i said I'm not doing that...I'm advicing users to
use the constructor (Foo.) or the factory fn (->Foo) cause they are
massively faster...In my case it not that big of a deal cos the user is
already is his namespace (in his game) so he does have access to
everything he needs. I just wanted to streamline the process and
essentially hide all the interop calls. No biggie for me...
hope that helps...
Jim
--
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
