Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: Rob Thorpe on 13 Jun 2005 10:19 Peter Seibel wrote: > "Rob Thorpe" <robert.thorpe(a)antenova.com> writes: > > > The textbooks I refer to certainly aren't lame since they use the > > normally accepted defintion of OO - ie. that written in most books and > > used by most programmers. I have never read a book that ties OO to > > polymorphism as you have tried to, but I would be interested to know if > > such a misleading text exists. > > Hmmm. What is this "normally accepted definition of OO" of which you > speak? Anyway, for such a misleading text, try: > > <http://www.gigamonkeys.com/book/> > > in particular Chapter 16: > > <http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html> Nice book, I had no idea it was available online, that's very useful. Christer Ericson has already made most of the important points, at least as well as I could have done. The difference between our viewpoints occurs when a program makes use of structures that encapsulate data and code together hiding the data's representation do not go as far as using polymorphism. I think you would call the structures in such a program ADTs whereas I would call them objects. (This is really only a small change in nomenclature). I use this definition for three reasons: 1) A great number of books use the same definition, such as those in the list Christer gives 2) Many programmers I have met use that definition 3) It is useful in talking to people about the code What I mean by (3) is that the step change in difficulty in understanding a program comes when the program is structured as above. Once data and code are encapsulated the program is much different than it would be if it were a procedural program. To someone who only understands procedural programs it would be difficult to understand. Whereas there's no step-change in understanding needed to comprehend virtual methods or indeed inheritance. Although this is only a small change in nomenclature it is an important one. For instance the (horrible) Windows API uses what I would consider object-orientation, through RegisterClassEx, CreateWindow etc. But it doesn't really support polymorphism.
From: Phlip on 13 Jun 2005 10:23 Rob Thorpe wrote: > Although this is only a small change in nomenclature it is an important > one. For instance the (horrible) Windows API uses what I would > consider object-orientation, through RegisterClassEx, CreateWindow etc. > But it doesn't really support polymorphism. The Window Procedure bound to each window, to handle its messages, isn't polymorphic? (About "horrible", farbeit from me to defend Microsoft, but I'd like to see /you/ invent an event-driven windowing system that can bind to a wide range of non-OO languages...) -- Phlip http://www.c2.com/cgi/wiki?ZeekLand
From: Phlip on 13 Jun 2005 10:27 Rob Thorpe wrote: > Yes. I was saying that it's not necessary to have data and code bound > at runtime to have object. It could be done at compile time. Is this C code "object oriented"? void operation(struct object * pObject); It binds data (struct object) with code (operation()) at compile time. Or would the dot notation aObject.operation() make it object oriented? > What does the Liskov substitution principle have to do with anything? If you declare "An OO language must support LSP", that implies an OO language must support polymorphism. Otherwise either nothing can substitute, or the caller must remain aware which substitution occurs. -- Phlip http://www.c2.com/cgi/wiki?ZeekLand
From: Rob Thorpe on 13 Jun 2005 10:39 Phlip wrote: > Rob Thorpe wrote: > > > Although this is only a small change in nomenclature it is an important > > one. For instance the (horrible) Windows API uses what I would > > consider object-orientation, through RegisterClassEx, CreateWindow etc. > > But it doesn't really support polymorphism. > > The Window Procedure bound to each window, to handle its messages, isn't > polymorphic? You're right, I'm wrong. I appear to have left my brain at home today. > (About "horrible", farbeit from me to defend Microsoft, but I'd like to see > /you/ invent an event-driven windowing system that can bind to a wide range > of non-OO languages...) True. There could be less unnecessarily weird detail though, like returning true and false opposite ways around for processing dialog messages and processing normal message loops. Anyway I won't try to write anything better today while my brain is at home.
From: topmind on 13 Jun 2005 11:52
> Since OO is NOT about either inheritance trees or polymorphism, > developers who use neither may still be using OO. I didn't really mean it that way. What I meant was that developers tend to use procedural techniques wrapped in classes. But this does get into the issue of what the definition of OO really is, and that question has no consensus answer. -T- |