From: Stuart Zakon Date: 2000-09-13T02:10:02+09:00 Subject: [ruby-talk:4908] Re: closures In article <200009112050.QAA04613@toolshed.com>, Andrew Hunt 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.