Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: Dmitry A. Kazakov on 12 Jun 2005 08:11 On Sun, 12 Jun 2005 07:27:44 -0400, CTips wrote: > Robert C. Martin wrote: >> On Fri, 10 Jun 2005 18:57:21 -0400, CTips <ctips(a)bestweb.net> wrote: >> >>>topmind wrote: >>><snip> >>> >>>>OO is good for .... shapes. >>> >>>Not really. Anytime someone comes up with the shapes example, ask them >>>how they would add the method: >>> >>>class shape { >>>// true if object has any points in common with <B> >>>boolean intersects(shape B); >>>} >>> >>>See how quickly mind-lock sets in.... >> >> That one is not so hard. Simply algebra can solve it without too much >> difficulty (I've done it). The tougher one is: > > Nah, the problem isn't the implementation. Its the fact that you have to > (in general) have to write a separate function for each _pair_ of > subclass types. Thus if you have the following sub-classes of shape: > square, circle, koch_snowflake > you will need to implement functions > square_with_circle > square_with_koch_snowflake > circle_with_koch_snowflake. > > Now if you introduce another shape, say a mandelbrot set. Then you need > to introduce another 3 functions: > {square,circle,koch_snowflake}_with_mandelbrot_set > > This means that you need to know _ALL_ other shape sub-classes out there > before you can actually implement the function intersects(). No, Robert's point was that if you have some generic shape or more general classes of shapes, then using them might reduce the geometric explosion of the variants in the case of multiple dispatch. For example squares, and rectangles etc could be handled by rectangles. Static polymorphism will suck here, especially if the structure of such classes is more or less complex. Dynamic polymorphism is much better, provided that multiple dispatch is supported. But even that might be too weak if the structure of classes from the intersection point of view, drastically differs from one from, say, union's view. This does not devaluate OO or polymorphism. It only shows that type relations, such as supertyping, should be more dynamic. Robert of course would say that this is why dynamic languages are better (:-)), but I would, that we rather need better type systems... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Charles Richmond on 12 Jun 2005 12:08 CBFalconer wrote: > > Gerry Quinn wrote: > > > ... snip ... > > > > 2. Chess pieces really are properties of a chessboard rather than > > things in themselves. A piece is meaningless without a board. > > > > Example: > > bool King::CanCastle( bool kingside ) > > { > > // Am I in check? > > // Have I moved? > > // Has the Rook in question moved? > > // Do any pieces block the intervening squares? > > // Do any opposing pieces attack the intervening squares? > > } > > Could be a long old function to write based on interrogating other > > pieces... > > Have pushed wood for over 60 years, and the question of castling > out of check has never come up. I didn't realize it was illegal. > There are various chess books around, but I can find nothing with a > set of rules! > You can get some chess rules in Acrobat (.pdf) format at: <http://www.ihsa.org/activity/ch/ 2004-05/chess%20rule%20book%2004-05.pdf> On page 13, Rule 6, Article II says: "Castling is momentarily prevented if a) the King is in check (Rule 10), b) the square which the King must cross is occupied, c) the square which the King must cross is attacked by a chessman of the opponent, d) the square which the King will occupy is is attacked by a chessman of the opponent, or e) any chessman occupies a square along the rank between the King and the Rook towards which the King will move" -- +----------------------------------------------------------------+ | Charles and Francis Richmond It is moral cowardice to leave | | undone what one perceives right | | richmond at plano dot net to do. -- Confucius | +----------------------------------------------------------------+
From: topmind on 12 Jun 2005 12:49 Laurent Bossavit wrote: > > Again, you describe "edits" in terms of a hierarchical taxonomy > > Nope. The type Edit can be an interface in Java terms, or a protocol in > Smalltalk terms. No inheritance required, no mutual exclusion implied. > > I have described the type Edit as an "umbrella term"; an abstraction. > One object can perfectly well be an Edit and several other things as > well. That is not much different from having a flag/attribute that says a record or tuple is "editable", just more syntax. Example: table: message -------------- msgID msgText isEditable (boolean) ... In fact, my wiki has something similar to this to make some messages only editable by the administrator. > What matters is that there are a number of classes of objects > which play the role of "Edit" in a given computation, and we can say > everything we have a need to say about that role in one and only one > place. We say nothing about the roles that can played by the very same > objects in other computations. > > Polymorphism is a well-known phenomenon in molecular biology. A protein > folds up for form a "slot" on its 3D surface. Another protein may fit > into the first only if it has the proper shape for that slot, called a > binding site. Now, more than one protein can have the proper shape to > fit into that slot. This mechanism is fundamental to, for instance, > vaccination. But each protein has to be evaluated for fit on an individual basis. That can also be modeled as an attribute in a record: table: protein -------------- proteinID canFitIntoSlot_A (boolean) canFitIntoSlot_B canFitIntoSlot_C .... Actually, a many-to-many table would scale better: table: slotFits ---------------- proteinRef (foriegn key) slotRef (foriegn key) By using attributes instead of behavior to indicate such, we can use higher-level "maths" on such info. There are more known "maths" for attribute processing than behavior processing, but OO tends to be behavior-centric in its interfaces, limiting it. > > In other words, Nature invented polymorphism ages before we rediscovered > it in software systems. It is a matter of perspective. It looks like it invented relational to me. > The designs Nature invents tend to be "smart > moves", structures that are so effective that even the undirected, > relatively inefficient design process that is evolution will inevitably > stumble on them. Actually in the real world, life is a big messy graph (network). Programming paradigms are only useful lies that humans create to (attempt to) simplify their view something they are interested in. OO no better models reality than relational + procedural. They are both Turing Complete. Relational just makes it easier to custom-tune one's view of such info for human analysis. You talk about "having everything for X in one place" above. Well, relational makes it easier to group stuff in one place as needed. It is impossible to put all related factors in one place at the same time in a 3D world, so as-needed dynamacy of view is helpful. OO just hardwires one particular view into the code. Get meta. > > Laurent -T-
From: Daniel Parker on 12 Jun 2005 12:40 "topmind" <topmind(a)technologist.com> wrote in message news:1118546740.145313.205320(a)g43g2000cwa.googlegroups.com... > Jeff Brooks wrote: >> >> OO is the standard right now. > > That is hogwash. Most developers do not use OO, just OO languages. I suspect that's probably true, more and more of them are plugging their code into OO frameworks, and using classes designed according to OO principles, but they themselves are not using OO techniques. Switch statements come naturally to them, no good to speak to them of polymorphism, polymorphism would only frighten them. Regards, Daniel Parker
From: topmind on 12 Jun 2005 12:59
> > > Outstanding, you finally have the opportunity to demonstrate > > > the advantages of your preferred programming approach over OO in > > > the context of a real application. Robert Martin has already > > > provided a link to his implementation -- let's see yours. > > > > 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). > > Security through obscurity is no security at all. I did not mean to imply that was the *only* security mechanism I used. It is just one that adds to the total security. Hackers not having the code increases security. (OSS inspection is not an issue here because it is not OSS at this time.) > As you note, > there are a number of Wiki implementations extant; it seems unlikely > that making the code to yours available would cause you any harm. I don't see what the existence of others has anything to do with the security of my version. > > At the very least, you could support your claims regarding > polymorphism by publishing enough of your code to allow comparison > with FitNesse. It sounds like too many different applications are rolled into one to compare anyhow. Somebody is making another Emacs :-) -T- |