The definition and essence of "object" is not always agreed upon
(encapsulation, polymorphism, state, ...), but since you're wondering
about objects versus functions (purely functional), the "versus" implies
a difference about an object that makes it impure, or the comparison
isn't so helpful. If an object was simply an enhanced pure function it
would just be better. So the key is that it is /impure/.
In terms of your first question, multiple dispatch is therefore a
different kind of concern (polymorphism) than the opposing difference
between object and function (purity). One can achieve polymorphism
either through doing something different based on argument types
(multiple dispatch) or doing something different based on the actual
type of thing being operated on (sub-object type of generic object
method--single dispatch).
If you're doing collision detection, multiple dispatch is useful. You
can write something like "(cartesian-prod collide? objects)" which
presumably passes every object paired with every other object to
collide?, which depending on the object types, handles the collision
appropriately (e.g. friendly fire is disabled by not detecting player
missiles hitting friendly infantry).
If instead you want to accelerate a vehicle, you can use the vehicle
itself with its polymorphic accelerate method "(send vehicle accel)" to
accelerate either a motorcycle or truck without caring what the actual
subtype is. The thing is, multiple dispatch generalizes this (multiple
dispatch generalizes single dispatch clearly...). The vehicle
acceleration is also handled by a multimethod that could be called
"(accel vehicle)". It's like collision detection in that it accelerates
based on the argument type--there just happens to be exactly one argument.
So there's really nothing special about objects and polymorphism *gasp*
as they are just a gimped way of dispatching compared to multimethods!
This brings us back to state. An object (really a closure) is useful
because it contains state (so does a plain "structure" type, so arguably
I'm implying the encapsulation is useful as well). If one is attempting
to maximize the use of an object/closure, it seems they would have to
take advantage of this state. So one would use an object not so much
for "extensibility" (which is inferior to the kind granted by multiple
dispatch) but for mutable state.
I must therefore conclude objects are for things like simulations and
other real-time, especially interactive applications where things change
over time. There is also functional-reactive programming, which aims to
bring "pure state" through functions that take time as an implicit
parameter, and this has advantages and disadvantages (space/time leaks,
sometimes getting infinite loops from difficulty reasoning about whether
an update affects something "immediately" or in the next full "update
cycle" (e.g. Yampa has both various switches and various comparable
delayed switches to implement either)). But ultimately, if one is
choosing an object-oriented approach, they should be doing it for the
mutable state (or at least encapsulation).
If you just want polymorphism, multiple dispatch is flat out more powerful.
____________________
Racket Users list:
http://lists.racket-lang.org/users
