Hi, On 5 Nov., 08:31, Konrad Hinsen <[EMAIL PROTECTED]> wrote: > That's exactly my point. Multimethods may well be sufficient or even > superior for implementing OO concepts useful in Clojure. We will see > when someone actually uses them this way (or has it already > happened?). But as long as the most important interfaces (sequences, > maps, numbers), which happen to be the ones also used by the built-in > types, don't use the same mechanism, there will always be first-class > and second-class citizens in Clojure's datatype universe.
I don't think that there are first-class and second-class citizens. They just have a different aspect. Having pure Clojure "classes" with multimethods might well be integrated and nice, but you get problems when you have to interface to Java. On the other hand using Java classes gives you easy interface, but you have to live with gen-class. So which one is first, which one second class? I think each solution has just different Pros and Cons. What would interesting, is the question, whether both approaches could be combined. We make a Java class (via gen-class), which gets a default implementation for each method, which references a similar named multimethod instead of the Class-methodName. Clojure "classes" deriving from that class do not provide an a Java method themselves, but register with the multimethod. The Clojure code could use the multimethods, while there are still the methods available for a Java interface. So the downside would be that one can only inherit from one such prototype class (since it needs to be a class, not an interface, for the default implementation of the methods) or one has to respecify the method - multimethod translation in all sub classes. Maybe a modified gen-class could support? (These are just random thoughts. Maybe they make sense, maybe not.) For the built-in datatypes: I implemented nth and get as multimethods (as some kind of proof-of-concept), but Rich was not very interested due to performance issues and the fact, that the datatypes are used internally in very low-level areas. I don't really follow the argument about monkey patching. I think it's not monkey patching at all, since the multimethods only define the interface. So I don't modify a thing which is returned by hash-map. That's still a hash map using the hash-map implementation. - http://clojure-log.n01se.net/date/2008-10-06.html#13:18 Sincerely Meikel --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
