Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: topmind on 10 Jun 2005 00:22 > Topmind, nobody is going to respond to statements like > this, because everybody is going to assume that you > haven't done your homework and > won't understand the response anyway. What > would be the point? CopoutRedHerring. Science is independent of me. Just produce solid evidence or stick your OO braggin' where the sun ain't shine. In other words, a place as dim and smelly as your evidence. > But if you took one of RCM's papers off his web site, > and prepared a serious critique that demonstrated > both that you understood it and also that > you disagreed with it, RCM would very likely > respond to that. But all his examples are device drivers. I *already* agreed OO is good for device drivers. But so far it is a one-trick pony. Make that two trick: Device drivers and shapes. What about something like an airline reservation system, a student grade tracking system, and inventory system, a finance estimating system, etc. Maybe they are not glamorous or fun, but THAT is the kind of thing that most developers work on. I am sick and tired of device drivers, animals, and shapes. I gotta force OO out of its comfort zone in order to expose it for what it is. -T-
From: topmind on 10 Jun 2005 00:46 > You may investigate this by looking at the source code of this > particular program. You can download it at www.fitnesse.org. I see things like socket examples. Regarding your wiki example, I actually wrote my own wiki about 5 months ago. At first I decided to use files instead of a RDBMS for the hell of it. But, I wanted to keep open the possibility of later switching to a RDBMS. Thus, I considered the idea of a generic wrapper around the "persistence mechanism" (cough). But then I realized I had to make it rather low level to deal with a lot of crud that RDMBS take care of for me. I gave up the generic idea, tossed the wrappers, and the code was smaller can cleaner. Things like *concurrency*, searching, and cross-referencing were made pretty simple by the RDBMS. A generic interface that can handle 3 of files, RDBMS, and RAM is going to be bloated and end up reinventing a database more or less anyhow. You essentientally wrapped away from RDBMS by almost building a DBMS of your own. Not very good "reuse" if you ask me. RDBMS are more than just a "persistence mechanism". They are "attribute managers", and if you know how to use them properly, they handle a lot of grunt-work for you. A RDBMS *is* an interface, by the way. Think about that long and hard. -T- oop.ismad.com
From: Rob Thorpe on 10 Jun 2005 04:18 Phlip wrote: > Rob Thorpe wrote: > > > What you've written above gives a basis for understanding the problem. > > But you've missed an important part, to have an object-orientated > > program you need data and subroutines connected together in some entity > > called an "object" or "class" depending on the terminology. > > "I can identify Encapsulation and Inheritance as aspects of the 'leverage' > term in my definition. They help make fOO integral to a system." My point is, it is not necessary to have polymorphism, inheritance or jump tables to bind code and data into an object. All that is necessary is that the two things are presented together. > > > By your definition this program is not fOO, I would agree with that. > > However, by the normal textbook definition of object-orientation this > > program is OO. > > OO programs (and fOO programs!!) enable the Liskov Substitution Principle. What does the Liskov substitution principle have to do with anything? A program like that I describe could fulfill the Liskov substitution principle, or it could break it, it's beside the point. Of course with a complex enough pattern of inheritance and complex enough object behaviour it becomes hard to obey it (or indeed do much useful) without polymorphism. > But, agreed, some textbooks are lame. 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. > > The books I have read and the programmers I have known in the past have > > always used OO in the way I do above, not tying it to polymorphism. > > Maybe terminology is simply different in the field you work in, > > terminology in OO tends to be confused, but it is different from common > > usage. > > My field is The Church of the SubGenius. I am a disciple of Bob. ;-) Ah, that explains a lot. Personally, I worship at the church of the four X's (at least when in Australia).
From: Dmitry A. Kazakov on 10 Jun 2005 04:44 On Thu, 09 Jun 2005 16:13:48 -0500, Robert C. Martin wrote: > I don't think so. Polymorphism is the ability for an object to > respond to a message in a manner that is consistent with it's type. Isn't it rather strong typing? The definition "one interface, many implementations" is IMO more consistent, though admittedly vague. What you describe is rather a "strong typed" reaction to polymorphism (of objects and methods), i.e. dispatch. > Or, to get very concrete, OO is a way of structuring programs such > that data structures are manipulated by functions called through jump > tables contained by those data structures. Ooch. Can a goal of software design/structuring/etc be "calling functions through jump tables"? You belittle OO! (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Gerry Quinn on 10 Jun 2005 06:19
In article <Vx0qe.6494$_A5.5126(a)newssvr19.news.prodigy.com>, phlip_cpp(a)yahoo.com says... > Gerry Quinn wrote: > > > > Or do you still claim OO is not about polymorphism? > > > > Yes. > > Then I pick a new word, fOO. The definition of "fOO" is "a style of > programming that leverages jump-tables, or their equivalents, to bind > behaviors to messages at runtime." Behaviours of what? Messages to what? input "English or French?", lang$ langid = 0 if asc( lang$ ) = 'f' langid = 1 end if if langid = 0 print "Click to play music?" else print "Clic pour exécuter la musique" end if if buttonclicked() if langid = 0 play "godsavequeen.ogg" else play "marseillaise.ogg" end if end if end That seems like an example of fOO in action. The run-time behaviour of the program is bound to the input message, using the equivalent of jump tables. A bit messy though. If I didn't have objects, I could still do fOO in more complex cases, but I would soon have even worse spaghetti. > With this word fOO, I can identify BASIC as "not fOO". VB Classic is "almost > fOO", and VB.NET is "fOO". > I can identify a program written in Smalltalk that stuffs all its statements > into one big unstructured method as "not fOO", and I can identify a program > written in C that uses pointers to functions stored in structures as "fOO". > I can identify Encapsulation and Inheritance as aspects of the "leverage" > term in my definition. They help make fOO integral to a system. How so? It seems to me that these object features are useful in practice if you want to do fOO on a C-like language. They come first. BASIC can do fOO just fine. But fOO on BASIC doesn't look much like anything one would want to do. > My word fOO is easy to apply, because it's narrow. Find the jump-table, or > equivalent, and we got fOO. > > My word fOO is distinct, meaning any two engineers can agree independently > whether a system has my fOO. > > The easy and distinct properties together lead to a third property. Because > fOO relates to very important programming topics, and because two engineers > who know my definition of fOO can say "fOO" to each other all day and know > what each other mean, that makes my definition useful. > > Definitions should be easy to apply, distinct, and useful. > > In terms of "correct", what is the difference between my word "fOO" and this > "OO" word you use? fOO doesn't have anything to do with objects. They aren't even on the same planet. The only connection seems to be that you have discovered that OO allows you to do fOO better than in the non-OO example above. But it allows you to do lots of things better. - Gerry Quinn |