Hi, 2009/3/31 Rich Hickey <richhic...@gmail.com>
> Here's how I think about it: > > - Hierarchies have nothing to do with multimethods/GFs per se. True, So, along the lines of my previous post, could it be made possible to let the user provide its own multimethods "candidate dispatch-values filtering" and "candidate dispatch-values narrowing" if needed ? And also, maybe, try to not add hierarchies concerns in general multimethods declarations : Currently, defmulti accepts a hierarchy as an optional parameter, and it seems to me that it contradicts what you wrote above, that "Hierarchies have nothing to do with multimethods/GFs per se." Or maybe it's a problem with my comprehension of a subtlety of english ? Making multimethods more generic could also help the clojure ecosystem work on a solution to the problem of multimethods working on hierarchies (which could still be made the default "flavor" of multimethods, thus allowing the 'hierarchy' optional parameter to remain valid with the "clojure hierarchies" multimethods flavor), while still starting from the same "building block". Sorry for using this thread as a way to speak one more time about the possibility to make multimethods more general, but since nobody reacted to my previous posts either bashing me or plussing me, I'm still not knowing if you consider it a good idea or not, and for which reasons. Regards, -- Laurent --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
