In Clojure, the closest thing to an object (short of implementing a
class in Java or using gen-class) is the map. But the more I play
around with using maps to implement the kinds of things that objects
are used for in other languages, the more I'm feeling that maps don't
quite cut it.
One problem is that Clojure doesn't really have hooks for altering the
way equality is performed on things like maps. For example, let's say
fractions aren't built in to Clojure, and I'm building my own
representation for fractions using maps. Even though the
*implementation* is a map, I'm no longer thinking of it as a map, but
as its own data type. And I may very well want to define a new notion
of equality, for example:
(= {:numerator 1 :denominator 2} {:numerator 2 :denominator 4}) should
be true. But there's really no convenient way to do this in Clojure.
A map, no matter how you choose to think of it, is still just a map,
and will always use its own built-in notion of equality.
Konrad has written a library that turns equality into a multimethod.
This provides the hooks for altering equality for maps, but there are
a lot of questions in my mind about how well this will coexist with
other Clojure code and just how severe the performance impact will be.
David Nolen's example on this thread is another instance of wanting to
tweak the equality semantics for a certain kind of map.
Another problem that has already been "solved" by many OO languages is
that initially it is most convenient to code certain things as
properties of the object, and somewhere down the line, you may want to
change property access into a method call. Most newish OO languages
have some way to do this, so that you don't have to start out making
oodles of getters and setters to make your API future proof. Timo
pointed out the other day that if you start out modeling data as a
map, and eventually want one of those pieces of the map to be
dynamically computed from other elements, there's no convenient way to
change this. All client code that uses assoc and get to simply
retrieve the field from the map must be changed, or the API must use
explicit getters and setters from the outset.
So this suggests to me that, although maps work fine for a lot of
lightweight object-like things, Clojure would benefit from something a
bit more sophisticated for more complex use cases where you want to
say, "This thing is a map, but I'm no longer thinking of it as map,
but as a representation for a <blah>" Such a construct would
hopefully eliminate the need for explicit tagging to work with
multimethods, as well as providing hooks to customize equality,
hashing, accessors, setters, visibility of elements, etc.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
