From: Robert Klemme Date: 2004-02-24T04:49:47+09:00 Subject: Re: Interesting article on the shortcomings of the OO model "Phil Tomson" schrieb im Newsbeitrag news:c68ca8f2.0402131630.72097e11@posting.google.com... > http://java.sun.com/developer/technicalArticles/Interviews/livschitz_qa.html > > She argues that objects (as now conceived in OO programming ) fall > short as an abstraction for reality. She says we need also to have > 'processes' and 'conditions'. Though she never really defines these > terms, they do seem familiar from the Hardware Description Language > world. I suspect a process in this context is a block of code that > gets launched when a condition becomes true, but this is not like some > kind of if statement like so: > if condition do something > > It's more like: > process(condition) { something to be done } > process(condition2) { somethingelse to be done } > > The two processes constantly monitor the conditions and when their > respective condition becomes true the code for that process is > launched. (this is how it is with HDLs)... of course, I could be > totally misinterpreting what she means by 'processes'. That sounds quite technical to me. When regarding the abstraction "process" and "condition" I prefer to think of them as "when a condition is met, the process is started. If I do understand her correctly, it's this level that she's talking about. Kind of hiding all that event sending of todays GUI systems. Instead you just define somewhere "button x pressed AND NOT text field y.empty => load file text field y.contents". > she also argues that we need new forms of code reuse other than > inheritance. > > Speaking of which... I know this was discussed a year or two ago here, > but I find myself using inheritance less and less with Ruby. I'm much > more likely to use aggregation, mixins or to add methods to existing > classes. I actually can't recall the last time I used inheritance. Yeah, when I'm doing Java I use inheritance sparsely, too. Most of the time it's some abstract base class or interface that is filled with functionality. Another interesting point that she raises are relationships. I don't no other language than ODMG (which is pretty much dead) that provides for explicit definition of class relationships from within the language. There is no corresponding concept to the lines we draw in UML diagrams between classes. There are tools that are able to do code generation for various types of relationships, but there is no such thing as a language level definition of a relationship and its manipulations. The thing that always strikes me about this is that those relationships don't belong to a single class but to two or even more classes. That makes them difficult to express in OO languages which usually only know classes and their features. (C++ is not an example against this since it's by far not pure OO.) It would be nice to be able to do something like relation OrdersOfCustomer: Customer(1) => Order(n) and then customerFoo relate:OrdersOfCustomer Order.new customerFoo related?OrdersOfCustomer someOrder or something similar... > I wonder if some of the ideas posited in the article might already be > taking shape among the dynamic languages like Ruby. Especially in > regard to her comment on refactoring being a very painful process. Hm, currently I don't see it there. You have Threads in Ruby, but not processes that you just define and the system takes care of all the nifty details (starting, stopping, waiting until all processes have terminated etc.) Although it seems that this would not be too hard to do. We have conditions and boolean logic in Ruby, but there no mechanism that does automatic triggering of actions (yet). I imagine that it must be difficult to devise a most general mechanism that is able to react on arbitrary state changes *and* which is performant as well. Interesting thoughts nevertheless! Kind regards robert