On Mon, 07 Dec 2009 12:07:12 -0500, Laurent PETIT <laurent.pe...@gmail.com> wrote:
> 2009/12/7 Hugo Duncan <hugodun...@users.sourceforge.net> > >> On Mon, 07 Dec 2009 06:53:38 -0500, Rich Hickey <richhic...@gmail.com> >> wrote: >> >> > Yes, methods are not really functions. Thinking about them as closures >> > over the object is a good way to go - you can see that analogy in play >> > when you consider recur, which works with these methods, but could not >> > rebind 'this'. The recur case sealed the deal in the decision not to >> > include 'this' in the argument lists. >> >> I had a quick play with protocols, and the biggest problem I had getting >> started was realising that the signature of a method definition in >> defprotocol was different to the signature required to implement the >> same >> method in deftype. FWIW, I found it very non-intuitive. >> > And now that you've got it, do you still feel this non-intuitive. > Because I had the same feeling first: I thought I would never rembember > how things work and why put 'this-like args there, and not there ... > But now that everything "clicked in place", I feel the last status of > what Rich achieved to do the most natural and intuitive. I'll no doubt get used to it :-) A couple of things that would have helped me "get it": From the deftype doc: "Thus methods for protocols will take one fewer arguments than do the protocol functions." would (at least for me) be clearer as: "Thus methods for protocols are implemented with one fewer argument than in the protocol function definitions." The example of a deftype protocol implementation that is in the defprotocol doc string could be repeated in the deftype doc string. > Basically, what helped me was along the lines of what Konrad said : > * defprotocol and extend are "purely functional" : so you have to > specify > every argument, including the object the functions acts upon. > * deftype with embedded protocol definition for the type, or reify, in > the > contrary, do not define pure functions. They define methods. You cannot > get > them as values and pass them around like higher-order functions, for > example. And you must know this fact, it cannot be an implementation > detail. > So, since you know this fact, you remember that you're in a method > definition (in the general sense of object oriented languages : method > of a > class) and, as you do with e.g. java, C#, ... , when definining methods, > you > do not add the target of the method as an implicit argument. > > The big advantage I see to this is that once you get it, you don't have > anymore to remember where 'this is explicit and where it's implicit: it's > intuitive. > The other big advantage is that the use of recur inside these > functions/methods bodies continue to match exactly the signature of the > function/method (otherwise you would have had to remember that, e.g. in > methods defined via deftype, you must place an explicit "this" argument > in > the method arg list, but not place it in the recur calls ... :-( ) That explanation certainly helps describe and clarify the reasons for the difference. I still find it counter-intuitive that the definition follows the syntax of the functional world, and the implementation that of an object orientated world. However, I can't think of any suggestion to resolve this, and as you say it does reflect the reality of the situation, so I'll get used to it :-) -- Hugo Duncan -- 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
