Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: Peter Seibel on 13 Jun 2005 12:06 "Rob Thorpe" <robert.thorpe(a)antenova.com> writes: > 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). So I'm still curious what you (and others who take the "polymorphism is only an incidental feature of OO" position) say about programs written in languages generally not considered "OO" that use the (good) engineering technique of creating ADTs. Is a C program written in terms of structs and functions that operate on those structs OO? Does that make C an OO language? > I use this definition for three reasons: Just to be clear, definition of what? An object? Or object orientation. I draw this distinction because they aren't necessarily the same. Suppose for the sake of argument that I'm right and that having support for runtime-dispatched polymorphic operations is the single necessary and sufficient feature to make a language OO. It might still be the case that all OO languages happen to use an ADT-like structuring of code and data according to the definitions Christer cited. Support for creating such ADTs may even be a necessary (but not sufficient) feature of OO languages. On the other hand, if you're saying that support for creating "combining" data and operations on that data (what you call an object and I call and ADT) is the only necessary and sufficient characteristic of an OO language, then I'm still curious what languages you're thinking of that you consider OO that have this characteristic but *not* runtime-dispatched polymorphic methods. If you want to say C--at least when used the right way--is an OO language, that's cool. But then I'll say any language can be OO if used in the right way. But then I'd be curious to know if there's a term for that set of languages that support runtime-dispatched polymorphic operations. -Peter -- Peter Seibel * peter(a)gigamonkeys.com Gigamonkeys Consulting * http://www.gigamonkeys.com/ Practical Common Lisp * http://www.gigamonkeys.com/book/
From: topmind on 13 Jun 2005 12:14 > > I am sorry, but I am not releasing my wiki code anytime > > soon. Besides, I didn't make any claims, you did. Two paradigms are > > considered equal or unknown until objectively proven otherwise. > > Interesting. It hasn't taken you as long as usual to revert to > form. You only managed two or three postings where you seemed > genuinely interested in a discussion of polymorphism before reverting > to vacuous assertions and outright falsehoods (for the record, the > vast majority of Robert Martin's articles are not about device drivers > and I have not made any claims in this thread). Then provide specific URL's to non-driver examples. One given involved "bank account types", and I already gave my view on dividing accounts into "types". (Remember the debate about "what the customer really wants"?) If you want to discuss *specific* non-driver examples, all you have to do is give a URL and name the example rather than fuss about what I said or didn't say. Solve problems instead of fuss about them and hunt for blame goats. > > > How about we start with some smaller examples: > > How about you demonstrate that you really want to discuss the > topic and not just score debating points in your own mind. You claim > to have written a Wiki based on RDBMS technology. You suggest that > polymorphism is a less useful technique than those you used. Show > what you mean through comparison with FitNesse. You mischaracterized my viewpoint. But anyhow, what are the "types" being polymorphed in the FitNess example? We already discussed the "storage types" issue, so what is there besides that one? Let's take these taxonomies and run some change-scenarios against them. > Show that you > actually understand the technology you are constantly (and thus far > baselessly) criticizing. In short, show that you are something other > than the pathetic little troll you have proven yourself to be in the > past. Something tells me that no matter what I do, you will always see me as a "pathetic little troll". (However, few who've seen me in person would use the word "little".) My website is full of careful reasoning, change scenario impact analysis, and rebuttals to about 40 oop claims. It is not perfect, but it is 10 times more thorough than anything I have seen defending OO. Those who defend OO tend rely heavily on anecdotes. Anecdotes are not very scientific. Why the industry seems happy to rely on them is a mystery. My reasoning may be all wrong, but at least it is documented and does not rely on anecdotes, or at least if it does rely on them, I state clearly what they are (such as assumptions about future change patterns/probabilities). > > Sincerely, > > Patrick -T-
From: Christer Ericson on 13 Jun 2005 13:04 In article <m264wkq336.fsf(a)gigamonkeys.com>, peter(a)gigamonkeys.com says... > [...] > I don't really disagree with any of the authorities you cite [...] > However all these quotes seem to be describing what an object > is. Which is fine as far as it goes. But a different--to my > mind--question, is what features make a language OO? It's the latter > question that I'm interested in (and that I thought we were talking > about, but I jumped in mid-conversation so it's quite possible I'm > wrong). I wasn't trying to comment on the definition of 'object-oriented.' I was merely pointing out that the bit of your text that I posted back at you, which paraphrased read as "OO is the organization of a program in terms of ADTs" is incorrect (in that it categorizes e.g. SML programs as OO). It seems you yourself do not support your own sentence because you in this last post say "my claim is that support for runtime- dispatched polymorphic operations is both a necessary and sufficient characteristic of OO languages." I apologize for avoiding commenting on the "what then is object- orientedness" bit of your post. I don't have time to give a fully thought out response. -- Christer Ericson http://realtimecollisiondetection.net/
From: Rob Thorpe on 13 Jun 2005 13:45 Phlip wrote: > 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? This depends on the wider context. Taking two possible contexts:- * Let's say this function "operation" is the only function that operates on "pObject". The rest of the manipulation of pObject is done directly by pObject->foo = 5; etc. In this case this code is not object orientated, it's just has one function that is tied to a data structure. * Alternatively, let's say there are several functions like "operation" that operate on pObject. In fact, the programmer never need manipulate pObject directly or know what's inside it. In this case it would be OO code. It's written in a language that isn't object orientated, but it's OO all the same. > > 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. I haven't said anything so far about languages. If an OO language is to be any use for building OO code of significant complexity it must support polymorphism, the point I was making is about programs. In any given program polymorphism or subtyping may not be necessary. In quite a few programs it would be possible to subtype a class and meet the LSP without polymorphism. But in general it would be impossible to keep to the LSP in a piece of code of significant complexity. I don't think that a program that otherwise combines associated code and data should be classified as not being OO simply because it doesn't use polymorphism.
From: Phlip on 13 Jun 2005 13:49
Rob Thorpe wrote: > * Alternatively, let's say there are several functions like "operation" > that operate on pObject. In fact, the programmer never need manipulate > pObject directly or know what's inside it. In this case it would be OO > code. It's written in a language that isn't object orientated, but > it's OO all the same. That's encapsulation. > I don't think that a program that otherwise combines associated code > and data should be classified as not being OO simply because it doesn't > use polymorphism. The problem with your definition is it lets in Visual Basic Classic. Yuck! -- Phlip http://www.c2.com/cgi/wiki?ZeekLand |