5 ms·

Object Orientation doesn't imply "single dispatch / message passing" style of Object Orientation. Common Lisp's CLOS and Clojure's multimethods and protocols ar

by strlen 14y ago

Object Orientation doesn't imply "single dispatch / message passing" style of Object Orientation. Common Lisp's CLOS and Clojure's multimethods and protocols are also object oriented, albeit in a different style. Of course CLOS is far more powerful than what Clojure has, but I wouldn't be so quick to discard OO in Clojure. OO doesn't imply mutability: even in Java it's encouraged (per Bloch) to create "functional objects" -- objects that create other objects instead of mutating internal state.

fauigerzigerk 14y ago
It's always difficult to pinpoint the essence of a paradigm that doesn't have a formal definition. But I disagree with you. In my opinion, message passing is central to OO thinking. It's not a style. It is the essence if there is one at all. Sending a message to one particular object isn't just a method dispatch mechanism. It also defines "self" and hence what data can be accessed without breaking encapsulation - another principle of OO. Now, I'm not saying Clojure doesn't support OO. It does. What I'm saying is that whenever you go beyond thinking in terms of passing a message to one individual object you are using features that are not object oriented on a conceptual level. You could even do that in Smalltalk and it still wouldn't be OO.
- strlen 14y ago
  I think we can agree to disagree here. What about a language like Perl, where any reference (not just a reference to a hash) can be blessed and be used to dispatch methods? Would you say OO Perl is not OO? (I think you could argue either way). Personally I think CLOS is a very interesting mode of doing OO. You could always define define multimethods based only on the first argument. Some parts of CLOS (method interceptors) have also made it to Java in forms of AOP (and in fact the author of AspectJ is one of the authors of CLOS) -- which provides "magic" for Java frameworks such as Guice. While I also hate to Biblethump, but Alan Kay has also spoken very favourably of CLOS despite CLOS not being message passing. If you prefer, you can think of CLOS as a "meta OO" which lets you implement different OO behaviour including message passing. Back to Clojure deftype and defrecord do provide encapsulation, by the way: in types with :mutable-unsyncyronized fields can only be accessed via self/this pointer. I do agree that Clojure's protocols/multimethods aren't a full blown CLOS, but they could (sensibly) be called a form of OO (even if it's a form OO that differs greatly from Java and C++)

by strlen 14y ago

fauigerzigerk 14y ago

It's always difficult to pinpoint the essence of a paradigm that doesn't have a formal definition. But I disagree with you. In my opinion, message passing is central to OO thinking. It's not a style. It is the essence if there is one at all. Sending a message to one particular object isn't just a method dispatch mechanism. It also defines "self" and hence what data can be accessed without breaking encapsulation - another principle of OO. Now, I'm not saying Clojure doesn't support OO. It does. What I'm saying is that whenever you go beyond thinking in terms of passing a message to one individual object you are using features that are not object oriented on a conceptual level. You could even do that in Smalltalk and it still wouldn't be OO.

strlen 14y ago
I think we can agree to disagree here. What about a language like Perl, where any reference (not just a reference to a hash) can be blessed and be used to dispatch methods? Would you say OO Perl is not OO? (I think you could argue either way). Personally I think CLOS is a very interesting mode of doing OO. You could always define define multimethods based only on the first argument. Some parts of CLOS (method interceptors) have also made it to Java in forms of AOP (and in fact the author of AspectJ is one of the authors of CLOS) -- which provides "magic" for Java frameworks such as Guice. While I also hate to Biblethump, but Alan Kay has also spoken very favourably of CLOS despite CLOS not being message passing. If you prefer, you can think of CLOS as a "meta OO" which lets you implement different OO behaviour including message passing. Back to Clojure deftype and defrecord do provide encapsulation, by the way: in types with :mutable-unsyncyronized fields can only be accessed via self/this pointer. I do agree that Clojure's protocols/multimethods aren't a full blown CLOS, but they could (sensibly) be called a form of OO (even if it's a form OO that differs greatly from Java and C++)