I think the reason is that an interface means that the function must be 'inside' the class. I.e you can call (.method object). Since it isn't possible to extend a java class in that way, it isn't possible to use extend. In a defrecord body however, a new class is defined, which means that it's possible to define functions 'inside' that class.
Protocols on the other hand doesn't define functions 'inside' the object, they are simply standard functions. Jonathan On Sun, Jul 10, 2011 at 1:15 PM, David Jagoe <davidja...@gmail.com> wrote: > Thanks for your response Devin. > > I guess I had come to the same conclusion by the end of my email. But > I wonder if there is a more direct way of achieving the same thing > without using a macro that spits out a defrecord with in-line method > declarations? I had a quick look at the defrecord code and didn't > follow well enough to see what machinery is being used internally to > extend the record to the java interface. > > In short: why can I implement java interfaces within a defrecord body > but not when using extend? > > > Cheers, > David > > On 9 July 2011 02:35, Devin Walters <dev...@gmail.com> wrote: > > What I think Kevin meant to say was that you might consider using a > macro. > > > > If you have questions about specifics, please do reply. This group is > here to Help, and it would be a shame if a response like the previous one > steered you away from asking a follow-up. > > > > Sent via mobile > > > > On Jul 8, 2011, at 5:14 PM, Kevin Downey <redc...@gmail.com> wrote: > > > >> if only lisp had macros > >> > >> On Fri, Jul 8, 2011 at 12:16 PM, David Jagoe <davidja...@gmail.com> > wrote: > >>> Hi All, > >>> > >>> I am battling with how to deal with the difference between Protocols > >>> and Interfaces in a particular case. > >>> > >>> Consider the following code: > >>> > >>> (defrecord DomainTypeA [] > >>> SomeInternalProtocol > >>> (foo [this] "foo result") > >>> > >>> clojure.lang.IFn > >>> (invoke [this] "invoke result")) > >>> > >>> This code works fine. > >>> > >>> However, I have a number of domain types all of which must use the > >>> same implementation of foo and invoke. > >>> > >>> In the case off foo its easy: > >>> > >>> (defrecord DomainTypeA []) > >>> (extend DomainTypeA SomeInternalProtocol > internal-protocol-implementation-map) > >>> > >>> However I cannot do: > >>> > >>> (extend DomainTypeA clojure.lang.IFn some-implementation) > >>> > >>> because IFn is a java Interface. How would I get arount this? > >>> > >>> My use case is as follows: > >>> > >>> Every one of my domain objects needs to implement invoke in the same > >>> way, so I don't want to code it in-line on the record definition each > >>> time. The implementation is defined in one place and I eventually want > >>> a macro (e.g. defdomainobj but with a better name!) that would > >>> automatically hook up the IFn def. > >>> > >>> Hmm maybe I just answered my own question: > >>> > >>> Should I just write the macro that spits out the code in my first > listing? > >>> > >>> Thanks! > >>> > >>> Cheers, > >>> David > >>> > >>> -- > >>> 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 > >> > >> > >> > >> -- > >> And what is good, Phaedrus, > >> And what is not good— > >> Need we ask anyone to tell us these things? > >> > >> -- > >> 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
