so clients don't directly call the protocol functions they call print-ast which then checks to see if PrettyPrintable has been extended to the object and falls back to the default if it hasn't
On Thu, Aug 12, 2010 at 6:16 PM, Matthew Phillips <mattp...@gmail.com> wrote: > On Aug 13, 3:38 am, Stuart Halloway <stuart.hallo...@gmail.com> wrote: >> > Stu, (or anybody) I'd like to ask about a variation on this >> > point. How do you handle the case where you have a general >> > function that works for every type you'd like to implement a >> > protocol for (thus not technically needing to be in a protocol), >> > but maybe 1 or 2 of the many types have more efficient >> > implementations possible? Do you just suck it up and copy and >> > paste the general function around? Or is there a better way? Maybe >> > the new case function? >> >> This might be a job for a more granular protocol. Take a look at how >> granular Clojure's implementation abstractions are (even prior to >> the introduction of protocols). The Java interfaces often have 0, 1, >> or 2 methods. > > The scenario I'm thinking of is when you've already published a > protocol, and now want to extend it. Instead, you could just create a > new (granular) protocol, but that does seem to lead inexorably to the > IFoo, IFoo2, IFoo3, situation. > > A more concrete example: say I've defined a protocol for AST nodes in > 1.0 of a library, and later when developing 2.0 I discover it would > have been a good idea to have a "pretty-print" method on nodes to show > human-readable output. If the protocol had Trait-like characteristics > I could add pretty-print to the protocol, with a default > implementation that just prints the fields of the node, but override > that with a better implementation for some of the new record types I'm > including in 2.0. > > But I can't do that because, unless I've had the foresight to make > sure clients always mix in a base set of (partial) defaults that I > provide (which may be initially empty), then things break down. Sean > Devlin's ideas (referenced earlier on the thread) on making it easy to > mix in defaults would be great for this, but they don't really address > the issue I'm looking at here. > > Following Stuart's suggestion, I *could* just add a protocol called > "PrettyPrintable" with one method and implement it on some of the new > node types, but now I can't just call "pretty-print" on any node: I > need to write another function that checks if it's a PrettyPrintable > first and calls something default if not. > > I've had to do this sort of thing many, many times in Java: one of the > reasons I got excited about multimethods in Clojure is that they allow > me to transparently extend the system after the fact with no such > ugliness. > > Thanks to the superpower that is macro, I'm sure I could make a > defprotocol+ and a extend+ that do this, just wanted to check that > there's really no better way. > > Cheers, > > Matthew. > > -- > 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
