In article <200009112050.QAA04613 / toolshed.com>,
  Andrew Hunt <andy / toolshed.com> wrote:
> 	>In that sense, they are functionally equivalent to function
objects in
> 	>Python and anonymous inner classes in Java? Why does the OO
world treat
> 	>these so differently in each language?
>
> Well, in Java at least, the anonymous inner classes are described
> as "an ugly hack."  It was an expedient way to get the concept into
> the language without having to break too many other things.  It
> wasn't designed into the language in the first place.
>
> Languages evolve; it's an immense chore to add neat features in
> a way that is consistent with the basic metaphor of the language --
> just ask Matz :-).  Fortunately, he's really good at it.  Or
> he got all the good stuff in right off the bat, which helps as well.
>

Thing is, I wonder what the 'right' way to model this OO feature is
because function objects are like a fragment of an object. Is it a
function (method) or an object?? Questions like these are pivotal
because it appears to be the root of the reason why each OO language
handles it so differently.

How about comparing Ruby's closures to Python function objects?

Function objects are useful in polymorphic code because the client can
use the FO in a consistent way (like an interface) while the behaviour
and state may vary depending on the type of the instance.

This is what FO's accomplish in Python and, I believe, in the C++ STL
framework. Is this a goal for Ruby.

Of course, the question could be asked, "Why not just rely on
Interfaces instead to provide this functionality?" This would make
sense because they are well understood from a UML perspective (good for
modeling) and can be used pretty much across OO languages.


--
Stuart Zakon
Objects by Design
http://www.objectsbydesign.com


Sent via Deja.com http://www.deja.com/
Before you buy.