Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: topmind on 10 Jun 2005 16:31 > And bound to the RDBMS. You OO'ers always make that sound like a bad thing. Youses are DB-phobics. I don't want to be bound to OO, can we wrap that away too? (I agree that the DB tools are sometimes lacking in implementation and portability). > If we had done that, our tests would be too > slow, and we would have to ship the system to our users with some kind > of RDBMS attached. My RDB-bound wiki was not "slow". Anyhow, one can do something like this: function getWikiArticle(articleID) { if (sys::driver==RDBMS) {.....} elseif (sys::driver==Files) {.....} elseif (sys::driver==RAM) {.....} else {error()) } // end-function Thus, one can change the implementation without changing the interface. Now polymorphism fans will probably say that grouping by driver is better than grouping by activity. It largely depends on the pattern of future changes, which you and I have disagreed with in the past. Such case-statement-versus-poly debates go on and on. No need to rekindle that here. But I would really like to see poly in business-modeling issues, not storage and EXE distribution issues. > So if you are using ODBC or > JDBC, you are using OO techniques to talk to your database. Perhaps. But that does not mean polymorphism is good for everything. There is more to programming than writing drivers. As far as the ODBC user knows, it could be grabbing the drivers or the references to the drivers from the Windows Registry, which is a non-relational database. Lots of things can be "jump tables". Remember this response to your modem driver example?: http://www.geocities.com/tablizer/prpats.htm#dispatch -T-
From: topmind on 10 Jun 2005 16:48 And right off the bat in this link: http://www.ratio.co.uk/white.html They define a hierarchy of bank account types. I have ranted against this before. To satisfy how customers really want stuff, you just cannot use hierarchies. Customers want a smorgishbord, not hierarchies. See: http://www.geocities.com/tablizer/mellor.htm#customerplans -T-
From: Leif Roar Moldskred on 10 Jun 2005 16:58 "topmind" <topmind(a)technologist.com> writes: > And right off the bat in this link: So? You were demanding examples of OO on the web that wasn't device drivers; not examples of OO on the web that was likeable to you. (I very much doubt the latter exists anywhere.) (And from my experience, customers want a sysetm that _works_ and doesn't give a damned about how you make it work as long as it doesn't involve grand treason -- unless they can claim plausible deniability in which case they don't care about the how at all.) -- Leif Roar Moldskred
From: topmind on 10 Jun 2005 18:27 Leif Roar Moldskred wrote: > "topmind" <topmind(a)technologist.com> writes: > > > And right off the bat in this link: > > So? You were demanding examples of OO on the web that wasn't device > drivers; not examples of OO on the web that was likeable to you. (I > very much doubt the latter exists anywhere.) Huh? I was hoping to see demonstrations of polymorphism making software better (by whatever metric you propose) in something besides the common textbook domains. If you don't have/know one, then just state so. > > (And from my experience, customers want a sysetm that _works_ and > doesn't give a damned about how you make it work as long as it doesn't > involve grand treason -- unless they can claim plausible deniability > in which case they don't care about the how at all.) Software is generally going to be more change-friendly if it fits the pattern of future changes. If the customers don't give a damned about your internal hierarchies, then using hierarchies is probably not a good change-friendly bet (unless you want to force them to live by your arbitrary classification system and let them vote for your competitor with their feet). One would just spend a lot of time reshuffling the tree to handle new requests and/or new combinations of requests. I want a bank account that is BOTH savings AND checking perhaps, and to switch each such feature on and aff as desired. Are you really gonna create a Cartesian Explosion of sub-classes for each feature combination (existing and new)? I assumed being change-friendly was one of the bragging points of polymorphism. If not, then please state your measurements of betterment. > > -- > Leif Roar Moldskred -T-
From: Peter Seibel on 10 Jun 2005 18:28
Christer Ericson <christer_ericson(a)NOTplayTHISstationBIT.sony.com> writes: > In article <m2ekbas0l2.fsf(a)gigamonkeys.com>, peter(a)gigamonkeys.com > says... >> [...] >> <http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html> > > In it you say, "The fundamental idea of object orientation is that a > powerful way to organize a program is to define data types and then > associate operations with those data types." > > What you give here is the definition of an _abstract data type_ > (ADT), nothing more, nothing less. Functional languages in the ML > category, for example, all support ADTs as a way to "define data > types and then associate operations with those data types" but we > hardly call them object-oriented. > > The commonly accepted view is that _only_ when we add the feature of > enclosing _data_ in the ADT does it become an object. That is, the > fundamental idea of object orientation is to combine within an > entity (which we call the object) data and operations on that data. Commonly accepted by whom? And what do you mean by "enclosing". Anyway, I'd still maintain the difference between plain ol' ADTs and OO is that in OO you have runtime-dispatched polymorphic operations on the lumps of data we like to call objects. But the operations aren't necessarily "enclosed" in the object in say, Smalltalk, where you can add a method to a class at any time. And even less so in Common Lisp where the connection between generic functions and classes is through methods that specialize on one or more classes. -Peter -- Peter Seibel * peter(a)gigamonkeys.com Gigamonkeys Consulting * http://www.gigamonkeys.com/ Practical Common Lisp * http://www.gigamonkeys.com/book/ |