Why Oop Is Better

Discussion moved to OopArgumentsDebatesAndDiscussion

(I'm not Top as I was accused, but I'm not going to stand for fanboys 'moving' valid counter-arguments from a page without moving the original points, because that's suppression.)

And people wonder why I am paranoid about anonymous works. --top
- (People only accuse you because they're usually right.)
- Only about 10% as found in ObjectiveEvidenceAgainstTopDiscussion. Your bias against my opinions makes you magnify my errors and forgot your own. Humans are defective in that way. --top

No, it's called refactoring a wiki page. I've removed the utterly irrelevant thread-mode mess from this page, and placed it where it needs to go -- in a discussions page. I did the same with ArgumentsAgainstOop too.

Counter-points are completely relevant to an argument. Refactoring keeps all relevant content. What you did is NOT refactoring. If you were going to move the counter-points, you should at least leave the fact that they are disputed and point the reader to the dispute. --AnonymousDonor
I did. Do you not see the, "See also" link at the bottom of the page? --Samuel A. Falvo II
"SeeAlso" is for related content, not for rebuttals. A "See also" link at the bottom of the page is insufficient, especially when the target is a page that you have made large enough to bury the content.

However, not 'moving' material out of ArgumentsAgainstOop, but freely 'moving' everything on this page out is called favoritism, a trait found oh-so-commonly in fanboys who just can't stand to be exposed for what they are: wrong.

I'm not paying attention to, or involved in, the ArgumentsAgainstOop page. However, if I were invested in it, I would also object to a change in ArgumentsAgainstOop that removed counter-points.

So do us all a favor: leave what you read on this page alone, unless you have something valid to contribute other than stupid argumentation. Ditto for ArgumentsAgainstOop. Failure to do this will result in my petitioning to have your edits tracked by SharkBot.

If you're planning to use SharkBot to 'threaten compliance' with your goal to hide counter-arguments deep in another thread, you'll find yourself sorely rejected by Mr. Voorhis.
You make this sound as though it's some grand conspiracy. Sorry, anoni, you're dead wrong. I've refactored, left links appropriately pointing to a relevant discussion page. You then come along, destroy all my refactoring work, I try to restore it, and now the blame is placed squarely on me for "imposing compliance." Well, if you want, I'll impose compliance. I'd rather not. I'd rather, instead, that you continue your DISCUSSION on the discussion page, and leave this page alone, since it's obviously a rebuttal to ArgumentsAgainstOop. So, if you have arguments against OOP, PUT THEM IN THE @($*& ArgumentsAgainstOop PAGE. Why do you insist on making this so god-damned hard?
An argument against an argument for OOP IS NOT THE SAME AS an argument against OOP. The arguments presented DO NOT BELONG in the ArgumentsAgainstOop page. As to why I insist on making this "so god-damned hard" - it's because I'm upset with you for 'burying' all my work deep in a thread, and I don't believe your 'refactoring' work was any sort of neutral or reasonable, much less 'refactoring'.

{How about we first find a common consensus about the style of these kind of debates before we do any major reshuffling. I would point out that there is too much material to put both pro and con stuff in one discussion page. I'd suggest having a separate pro-discussion page from the con-discussion page. ControversialTopicTemplate shows what I feel is a pretty good format, although the "discussion" could be moved to a separate topic in the case where it is long. The intro has a brief outline of the arguments and con's, and the detailed debate on each topic hopefully follows the outline. However, in practice the arguments tend to interweave due to either carelessness or WaterbedTheory. It may take some refactoring to reduce the interweaving. --top}

Better subroutine name-space management for packaged device drivers and driver-like concepts because the routines are tied to the "handle" instead of global (or wider-scope) routines that must resolve the device. Thus, building a driver does not have to rely on a set of shared routines that are in a larger name-space.
If it is safe to model the domain via "sub-types", polymorphic dispatch can be simpler than case statements, especially if adding new sub-types is common.
- Countered by OOP users, many of whom see domain-objects as one of the big fallacies of inexperienced OOP users. See OopArgumentsDebatesAndDiscussion
Useful if there is a need to tightly integrate data/state and behavior.
- Countered in part by many OOP users, many of whom see integrating 'domain' data as an AntiPattern. Data related to the computation model is excepted. See OopArgumentsDebatesAndDiscussion
OOP seems to be a good fit to the way at least some people think about the world and/or their domain.
- Some experienced OOP users see this as an 'appeal' to a view that ultimately is harmful (domain-objects). OOP is sometimes a good fit to thinking about the program. See OopArgumentsDebatesAndDiscussion
OOP seems to support a larger team of developers at one time as it (the application/system being developed) can be partitioned into distinct parts/modules/etc. easier.

I don't know why you moved that there. That page is already too damned big. I plan to move it back in one month if there is no real objection. Related: OopDebateMetaDiscussion