On Wed, Dec 12, 2012 at 8:22 AM, Jim foo.bar <jimpil1...@gmail.com> wrote:
> On 12/12/12 00:16, Mark Engelberg wrote: > > I would much prefer to have some sort of core function that serves as a > polymorphic constructor. This way users don't need to require the concrete > implementations individually. > > > I faced the same sort of issue a couple of months ago. Just like you, I > wanted end-users to be able to instantiate their own records via a > polymorphic function in the core ns. In other words, I wanted a way of > instantiating records by passing only the record name (fully qualified of > course) and whatever parameters the constructor expects. If i understand > correctly this is what you're after yes? > 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. 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. -- 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
