Hacker News Reader

Comment by twism | Hacker News Reader

Didn't know clojure tries to do OO

I'm going to guess he meant clisp, clojure has a page specifically stating it doesn't do OO.

(though of course with tuples and multimethods...)

Clojure has a page specifically stating it doesn't take the traditional object-oriented approach - the Java/C++/C# one people are most familiar with: http://clojure.org/multimethods

It doesn't. Objects imply state and a set of methods to mutate that state, which is incompatible with Clojure's immutable-by-default design. Instead it provides tools that facilitate the same things as OO features: polymorphism via multimethods and inheritance via ad hoc hierarchies on names.

Aside from all the Java crap it has multimethods, but it doesn't really make sense to call them OO because there's no object that they're attached to.

OO is not about methods, it's about the data. Single-dispatch OO is just a special case of multimethod-based-OO, anyway.

(Remember the whole "sending a message to an object" thing? You do that with both variants. In the single-dispatch case, the method is a structure in the metaclass instance. In the multiple-dispatch case, some other helper object finds the right method. Same idea, though.)

You put it much better than I did; facts without rhetoric :-)

Multimethods are ambient actions. You could implement them with functions and any sort of type system. Maybe also a way to have variable-length parameter lists. If that's OO then functional programming is object-oriented programming.

Multimethods means that a method is dispatched not only on basis of the receveiving object (or read: first argument) but on basis of all arguments. The term is inherently related to OOP: http://en.wikipedia.org/wiki/Multimethod

Yes, functional programming is very similar to OO.

OO:

    class SomeType { 
        <data> ; 
        SomeOtherType function1() { 
            this.whatever ; 
            ... 
        }
    }

FP:

    data SomeType ...
    f1 :: SomeType -> SomeOtherType
    f1 this = whatever this >> ...

Same idea, different syntax. (Type classes will allow polymorphism, if that's what you're after.)

You are thinking of the abstraction in terms of its implementation. There is no reason why a method in a class would physically be in that class; the class just acts as a namespace:

   class Foo { method }
   Foo.method();

and

   (defmethod Foo.method ...)
   (Foo.method)

are the same.

Do you realize single-dispatching methods in class-based OOPLs are nothing but constrained generic functions? they're curried on one argument and nailed flat to the ground with a staple gun.

I don't know about Clojure, but Common Lisp's "multimethods" are OOP on steroids; you could layout your code vertically in a parent/child class heirarchy and it would look no different than a "normal" class-based inheritance tree; all you have to do is visualize the method call in prefix mode:

  object.method (arguments) = method (object arguments)

In essence, you could model Java and similar languages with a fixed and constrained Common Lisp. You just have to take its wheels off and lay it flat on bricks.

Interested parties can go and learn CLOS for the full story. Spoiler, though: not long after, Lisp will start to hover! you just can't hold somethings down. If you thought of objects in terms of a vertical class heirarchy, or a side-ways call chain or what have you; CLOS will make your visualization planes intersect and show you new dimensions you never imagined..

It's still OO, it's just not the style most people are familiar with. One can implement multimethhods in Java and C++, it's just cumbersome. (In fact, Stroustrup has said he wanted C++ to be able to do multiple dispatch at the language level, but he never found an expression and implementation that satisfied him in terms of performance and the type system.)

CLOS has had multimethods for years, and that is indeed OO.

Reply on news.ycombinator.com