interesting, the trick is to use foo.recs.ARecord... (extend-protocol AProto foo.recs.ARecord (handle [o] ;; do stuff ))
Thanks for that. On Wed, Feb 15, 2012 at 11:31 AM, Chas Emerick <c...@cemerick.com> wrote: > No; just add a (:require foo.recs) to the ns form of foo.prots, so the > defrecord form(s) can be loaded; this will generate the classes at runtime, > and avoid any ahead-of-time compilation. > > In general, AOT is rarely necessary, and almost always a hinderance. > > - Chas > > On Feb 15, 2012, at 11:13 AM, Jay Fields wrote: > > again, I haven't felt much pain, so I'm not sure what I'm saying is entirely > true, but... > > In the scenario I describe I have to :import the class created by defrecord > to reference it as part of extend-protocol > > For example > > in foo/recs.clj > (ns foo.recs) > > (defrecord ARecord [a b]) > > in foo/prots.clj > (ns foo.prots > (:import [foo.recs ARecord])) > > (defprotocol AProto > (handle [o])) > > (extend-protocol AProto > ARecord > (handle [o] > ;; do stuff > )) > > In that case, don't you need to record to become a class, so you can > reference it in foo.prots :import? > > I'd really love to be wrong, so I get rid of this occasional issue. =) > > Cheers, Jay > > On Feb 15, 2012, at 10:51 AM, Stuart Halloway wrote: > > I think this issue is related to using > defrecord > or > defrecord & defprotocol > or > defrecord, defprotocol, & extend-protocol > > I've never bothered to look into the simplest case at which it fails. I have > a namespace that has my defrecord, and another namespace that defines the > protocol and uses extend-protocol to add behavior for my record type. If I > recompile the namespace with the protocol everything is fine, if I recompile > the namespace with the defrecord the protocol stops finding the > implementation for the protocol. The solution is "rm -rf classes" > > As a work around I rm & restart my app if I ever change my record - which is > very rarely. > > > A better solution is not to compile defrecords during development. If this > is the default behavior of some tools, it is anti-incremental-dev and wrong > IMO. > > Stu > > > Stuart Halloway > Clojure/core > http://clojure.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 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 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 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
