Upfront you have to track multiple arities for the same method. If all your implementations are concealed in a single file that may be bearable.
Here we define protocols in a file (like xxx-api) and then conceal the implementations in different name spaces where they belong. Multiply the # of name spaces defining (maybe partial) implementations by the number of methods and arities, add to this the "did I reloaded all the name spaces ?" factor and now it starts to get complex. You may have a sharper mind than me or I am being extremely lazy but I choose to avoid these issues entirely :) One protocol method, one signature is enough for me. It could be also be that with 15000 lines of code with several protocols, we need some form of disciplin to keep things under control. I do use multiple arities when creating functions but this respects the principle of locality, everything in the same spot, not scattered at several places. Luc > but multiple arities correspond to different method signatures on the > interface level and in fact the protocol level as well...when you > implement either you really treat them as separate fns/methods...how > does the one complect (not implementing some arity) and the other > doesn't (not implementing some fn)? > > Jim > > > On 01/03/13 14:25, Softaddicts wrote: > > Precisely David and I were making a point specifically about methods with > > multiple arities in the same protocol. > > > > I do have protocols partially implemented on some occasions and there's no > > problem with that. The runtime error is quite clear if someone tries to call > > an unimplemented method. > > > > The problem I experienced is that using multiple arities complects the > > issue. > > It's harder to understand which arity is missing and what has been loaded > > first > > especially in the REPL were you may redefine stuff on the fly. > > > > This matches your own experience. > > > > Luc P. > > > > > >> Hi all, > >> > >> Since yesterday, I've been thinking about something David Nolen said in > >> my /"what on earth is happening?"/ post. In a nutshell, he suggested > >> that protocols *should* be fully populated. Luc from softaddicts agreed > >> and actually shared his own horrific experiences with non-fully > >> populated protocols. Before continuing I should point out that I'm > >> looking for a discssion - not a debate...learning is the ultimate goal > >> here...:-) > >> > >> So let's just leave Clojure aside for a moment... > >> > >> In java, when we've got an interface that we want to implement we've got > >> literally no choice. We have to implement every single method/arities. > >> Consequently, whenever a particular method/arity doesn't quite fit from > >> the implementer's viewpoint, it is implemented throwing an exception or > >> returning something irrelevant like null (most cases that I've seen > >> exceptions are thrown). everything fine so far yes? > >> > >> Now, let's move to Clojure...the backbone of every protocol is > >> essentially an interface right? Every time we leave an unpopulated > >> implementation of some protocol-fn the Clojure compiler generates > >> exception stubs for it in the implementers' code...in other words, we > >> may have left it unpopulated but Clojure populated it with that > >> exception stub. *How is that different from populating it and providing > >> the exception stub ourselves as we'd do in Java? *It is my understanding > >> that the compiler does that so that we don't have to repeat code (I > >> guess something similar to the 'with-open' macro). Is my understanding > >> that wrong? > >> > >> > >> thanks a lot in advance, > >> > >> 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 > >> --- > >> You received this message because you are subscribed to the Google Groups > >> "Clojure" group. > >> To unsubscribe from this group and stop receiving emails from it, send an > >> email to clojure+unsubscr...@googlegroups.com. > >> For more options, visit https://groups.google.com/groups/opt_out. > >> > >> > >> > > -- > > Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad! > > > > -- > -- > 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 unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad! -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
