Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: Jeff Brooks on 13 Jun 2005 22:50 topmind wrote: > Unfortunately, I don't want to release it public because I want some > security through obscurity. I might release snippets though. There are > plenty of existing wiki's implementations anyhow, and my approach does > not significantly differ than them (although I feel I factored better > than some of those I looked at). So you are not going to support your claims with any evidence as usual. If your past posts is any indication of your future behavior you will continue to complain that the OO people never provide any evidence and forget that your are guilty of the same thing. Jeff Brooks
From: Jeff Brooks on 13 Jun 2005 23:12 topmind wrote: > > Jeff Brooks wrote: > >>topmind wrote: >> >> >>>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 >> >>Classification hiearchies don't need to be used to model everything in >>OO. Your argument in this case is very weak. > > I didn't say they were. I was addressing a specific example of > polymorphism. "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." - topmind The link you supplied is also about issues with hierarchical classification. Jeff Brooks
From: Jeff Brooks on 13 Jun 2005 23:17 topmind wrote: > Again, you describe "edits" in terms of a hierarchical taxonomy or list > of mutually-exclusive choices ("sub-types"). How many times do I have > to say that trees and mut-ex. is poor modeling? How many times do we have to tell you that you don't need to model everything in OO with huge classification trees? Jeff Brooks
From: Peter Seibel on 13 Jun 2005 23:28 Christer Ericson <christer_ericson(a)NOTplayTHISstationBIT.sony.com> writes: > 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). Ah, well then we don't really disagree at all. You quoted, IIRC, this sentence: 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. However by "associate operation with those data types" I meant a bit more than just "define operations on those data types" though I see how you could read what I wrote as meaning the latter. However if you look at the very next sentence, I say: In particular, you want to be able to invoke an operation and have the exact behavior determined by the type of the object or objects on which the operation was invoked. I.e. I'm talking about runtime-dispatched polymorphic operations. And, indeed, I wind up the paragraph saying: This feature of object orientation [i.e. the one I started out the paragraph talking about] goes by the fancy Greek name polymorphism, meaning "many forms," because a single conceptual operation, such as drawing an object, can take many different concrete forms. > 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." Well, that's what I was trying to get at in that paragraph from which you quoted the first sentence. I perhaps colud have made it more clear that that's what I was trying to say; then, at least, we could be having a discussion on what I think is the more interesting question--is there any other necessary or sufficient feature of an OO language than runtime-dispatched polymorphic operations? > 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. Pity. -Peter -- Peter Seibel * peter(a)gigamonkeys.com Gigamonkeys Consulting * http://www.gigamonkeys.com/ Practical Common Lisp * http://www.gigamonkeys.com/book/
From: Jeff Brooks on 13 Jun 2005 23:34
topmind wrote: > > Jeff Brooks wrote: > >>There have already been a few examples posted. Read them. > > Nobody has provided a definite URL so far. Yes they have. Look at past messages. >>That's an illogical argument. >> >>Do you think if a customer doesn't give a damn about the structure of a >>procedural program that means the structure won't affect the future >>maintainability of the software? > > I am not sure what you mean. I am only saying that real world changes, > such as customer preferences, don't usually change in a hierarchical > way over time. If you want change-friendly software, your software > should not hard-wire itself to tree-based changes. Then don't hard-wire the trees into the code! >>That's an illogical argument. >> >>The problem would only exist if you had to model everything as a single >>rooted classification tree. That isn't true so your argument is meaningless. > > Are you suggesting multiple inheritance? There are ways of modeling non-hierarchical cclassifications in every OO language I have seen. For example: In java there is interfaces which support multiple inheritance. An interface can be applied to any node in a tree and do not have to apply to any parent of the node. This allows non-hierarchical classification in Java. In dynamic languages (Smalltalk, ruby, python, Objective-C etc) the structure of a tree has no impact on the ability to assign it. As long as the object can respond to the same messages that another object can it can be used no matter what it's parent is. In C++ there multiple inheritance so multiple parents are supported. In Self dynamic/multiple inheritance is supported so it's not a problem. In JavaScript it uses a prototype base system so different parts can be assembled together to support behavior from multiple "classes". etc etc >>How did you measure that polymorphism is worse? > > It is objectively more code rework if you want to change it to a HAS-A > model when trees fail. If you start out with a HAS-A model, obviously > it is easier to accept more has-a's without lots of code rework. Deep classification trees is considered bad OO. It's good practice to have a forest rather than a single tree for classification. Having lots of small hierarchies that have HAS-A relationships is the normal way things are modeled in OO. Bad design is always difficult to change which is true in procedural code as well. Jeff Brooks |