Are Oo And Relational Orthogonal Discussion Three

A 3rd installment of the popular topic of AreOoAndRelationalOrthogonalDiscussion:

---

Moved from BenefitsOfOo:

[EditHint: indentation needs to be refactored. Most bullet-points are not necessary]

Most of the claims on this page would melt away under the scrutinty of more realistic examples (at least for some domains). --top

I agree that OO does not effectively handle many-to-many relationships, multiple dispatch, fine-grained specialization, 'open' specialization, or complex queries. OTOH, neither does procedural, which was OO's main competitor at the time these claims were made.

Please clarify. OO's competitor is both procedural and relational. They compete with different aspects of OO. I agree that if by gun-point I was not allowed to use relational or databases, I'd probably prefer some OOP over just procedural. Limiting the discussion from powerful combo's would not be very useful, unless we want to pretend we're in the disco era. Procedural and relational compliment each other well without having similar territory to fight over. OOP half invents a database, but leaves out too much. --top

• Hmmm... I can see how my statements would be confusing. There are OO databases (OODBMS), which compete with relational, and then there is ObjectOrientedProgramming (OOP), which does not compete with relational. The two don't coincide or compete except when programmers start ReinventingTheDatabaseInApplication (which does happen, but is not a practice I recommend). In general, these applications of 'OO' should be evaluated separately. My statements above were made in reference to OOP, not OODBMS.
• Again, I disagree about OO not competing with relational. The VisitorPattern is a prime example of something that relational would do differently. When you make a choice to use visitor, you are un-choosing a relational solution. As far as OODBMS, some say there is no such thing because OODBMS do not have any real encapsulation. They only share OO's navigational structuring (that is, a mass wad of pointers with a dab of tree-ness), which almost nobody would promote if OO didn't do it. --top
• How does use of VisitorPattern "un-choose" a relational solution? Explain this to me in logical terms.
• A given solution cannot be both at the same time (at least not without making a mess). Therefore, it must either be an OO solution or a relational solution.
  • [What do you mean by this? OO and relational approaches are complementary rather than competing.]
  • Agreed. I feel TopMind is assuming the consequent here.
  • I don't understand why this isn't more obvious. There's some kind of translation/communication block going on. Take the DoubleDispatchExample. The solution is pretty much going to be either OOP, relational, or some other paradigm. --top
  • In DoubleDispatchExample, your 'relational weenie' example implements OOP techniques and stores (or references) the scripts/functions for each 'printer object' within the RDBMS. Refer back to page anchor OOP_tehniques_impl.
  • You mean code or references to code in data structures? OO has no monopoly on that. Lisp was doing it about 7 years before the first OOP language. I'm not sure what paradigm we should give that credit to. Perhaps none owns it. It was easy to do in machine language. Later languages made the technique more difficult, subtracting that ability, perhaps fearing it made programs less predictable. See HistoryOfCodeInStructures.
  • (page anchor not-just-code-in-structures) I mean dispatch based on associating 'objects' (printers) with 'code' (scripts) to process certain 'commands' (printing shapes) into which you'll need to feed both other data about that object (so that the script can print the shape to the right printer) and other data about that command (so that the script can print the shape with the correct size and position). And hand-implementation is the early stage in the life cycle for nearly all programming language methodologies and techniques - that doesn't make them any less OOP techniques, it only makes them less OOP languages.
  • Records = objects is too much word-play in my opinion.
  • Funny. I never suggested 'records = objects'. It is ObjectIdentity, and the ability to associate attributes with such an identity, that makes an object.
  • But anyhow, both approaches "put code in data structures" (or code references). In that aspect, they both use a similar technique, and I don't give OO credit for inventing that technique as described in HistoryOfCodeInStructures. Merely using a common technique does not break my overlap claim any more than both using QuickSort makes them non-overlapping. In one, the structure is objects tied together via references, in the other the structe is a RDBMS table.
  • History is irrelevant. Credit for the technique is irrelevant. That one has "put code in data structures" is, guess what? That's irrelevant too. OOP is not about 'code in data structures' (and many implementations do not put the dispatch code into the data structures). OOP is about dispatching messages and commands to things associated with object identity.
  • Regardless, your DoubleDispatchExample is a poor example if your goal is to demonstrate relational and OO not working together, even though I don't believe it a good example of them working together. Relational and OO are readily integrated by using OO to, according to database provided configurations, construct programs on the fly for processing 'inputs'... which may also come from the database. As noted elsewhere, the only thing RDBMS is missing to make this complementary union nearly perfect is the ability to 'subscribe' to queries with DeltaIsolation (e.g. via dynamic insert/update/delete events on the 'view' so subscribed).
  • The last 2 paragraphs are not clear. One is putting the code references in tables *or* they are putting them in objects/classes. It's a pretty strong dichotomy. They *are* fighting over territory. It's hard to be much clearer. You either put "the stuff" in tables, or you put "the stuff" in objects. --top
  • Your assertions are clear, Top. They're just wrong. OOP can be implemented using tables, at which point putting code references into objects/classes and putting them into tables will happily coincide. And that (hand-implementing OOP techniques using tables) is exactly what your DoubleDispatchExample does.
  • They are not wrong. If so, please re-word as formal logic. code-in-structures is NOT unique to OOP as already described. That is a fact. It's like saying that inheritance provide defaults by having the default behavior in the parent class; therefore, anything with defaults is "OO".
    • As formal logic: (A) OOP may be implemented using tables by associating object identity with properties (attributes, behavior descriptions). (B) If OOP can be implemented using tables, one will necessarily be putting the code references in tables *and* putting them in objects/classes. (C) Following from A & B, one can put code references into objects/classes and tables at the same time. (D) Therefore, your assertion to the contrary (that this "is a pretty strong dichotomy", exclusive "either/or") is in error.
    • You seem to be assuming that emulation is equivalence. Relational tables can be used to emulate OO (if that's what is happening) because tables are flexible and powerful, NOT because they "are" OO. OO can also emulate tables. TuringEquivalency. If I emulate SmallTalk in Java, does that mean that Java *is* SmallTalk?
    • No, I'm only assuming that emulation is "implementation".
    • See below at page-anchor "Turing".

  • Regarding your "code-in-structures" statement: I agree, 'code-in-structures' is not OO. But your DoubleDispatchExample, as I have already explained (at page anchor not-just-code-in-structures), is much more than 'code-in-structures'. Your DoubleDispatchExample also has the following traits: ObjectIdentity (foreign keys to printers), and dispatch to determine behavior based on recipient of request/command message (printer reference and shape identifier determines shape script... same as printer.drawCircle(), printer.drawRectangle()). ObjectIdentity and virtual message dispatch are among the strongest defining traits of OO, being about the only features common to all OO languages (many of which lack classes and referential inheritance). Your DoubleDispatchExample is a very clear implementation of OOP techniques, but using tables because you're a RelationalWeenie and wanted to find a way to include tables.
  • This seems to get into DefinitionsForOo. I disagree with your definition, but I will not take that up here. Further, "message passing" is rather open-ended. A function call is message passing. So is HTTP.
  • Indeed. But OO is not just message passing, either. It is message passing with certain properties: message passing to things with 'ObjectIdentity' such that how the message is processed is determined by the callee. Given that I just got past telling you that OO is 'not-just-code-in-structure', I'm starting to feel that you're repeatedly sticking your eye up right against the bark and saying that you can't see the tree.
    • To settle this, we'd probably have to settle on a definition of OO, which is difficult (NobodyAgreesOnWhatOoIs).
    • Even though when it comes to small details, NobodyAgreesOnWhatOoIs, there is a great deal of agreement. It's a bit like attempting to measure the length of a coastline when dealing with outcrops and tides when there are bets riding on the answer and the people making the bets are also deciding on how to measure the coastline. Despite all the minor politicking, everyone agrees that the coastline is at the edge of land and water and that it is at least longer than the shortest distance between two points on the coastline. Anyhow, the point of this analogy is: you're using 'NobodyAgreesOnWhatOoIs' in a manner to imply a level of disagreement that doesn't exist on that page. People agree on at least a few critical elements, and your DoubleDispatchExample has them.
    • I'm sorry, but I don't see a near consensus.
    • It's there. Perhaps you're too busy watching the battle at the edges to observe the common ground between those who are arguing.
    • OO's def seems like a Rorschach test: people project into it their pet methodologies, mental models, and techniques.
    • It only seems that way until you've worked with ProgrammingLanguageTheory enough to know how much the different OOPLs have in common, and how little design space they cover, relative to the wide variety of other language designs.
    • That's ArgumentFromAuthority. Debate rules either forbid it or downplay it.
    • It's a description from experience, yes. But it's fair game against your "Rorschach test" analogy, which is not an argument at all.
    • If you wish to explore this further, I suggest you do so under NobodyAgreesOnWhatOoIs, or a similar topic.

  • Overall, if we back up away from definition-of-OO issues, one is still faced with the implementation dichotomy of putting code (or code references) in table *or* in language classes. Thus, at least the OOPL (app language) is "fighting over territory" with the RDBMS. Do you at least agree with this? --top
  • I do not agree with that. Your DoubleDispatchExample is proof that there is no implementation dichotomy. And, even if you put aside the fact that your DoubleDispatchExample is implementing OO between its relational storage of DomainObject print drivers and procedural driven dispatch, that example does not serve as an argument (or even as evidence) that OO and relational are somehow "fighting over territory". All it shows is that you can use relational to implement OO.
  • PageAnchor: Turing
  • TuringEquivalency does not tell us anything new or interesting, all paradigms can emulate all other paradigms. There is still a design choice. It is as strong a dichotomy as one gets in paradigm land.
  • TuringEquivalency is about languages, not paradigms or methodologies. If you wish to claim that your RDBMS+Procedural solution isn't using an OOPL (emphasis on the L for Language), then I would agree with you. BUT (with lots of emphasis), your DoubleDispatchExample is still a direct implementation of the OOP methodologies, and will have various properties (good and bad) that are implied by OOP methodologies.
  • Are you saying there is nothing equivalent to TE with regard to paradigms?
  • You could probably invent something, but paradigms are about how to express behavior rather than what behavior is expressed, so you'd be better off coming up with some formal description of ExpressivePower rather than computation equivalence.
  • As far as using the above technique, again again again, it is not native to OO. Other paradigms/techniques have been using it since the beginning of electronic computers. I will agree it shares techniques commonly found in OO, but that does NOT mean it *is* only OO. To be clear, I agree that multiple paradigms can share the same technique. We are going around in circles here. And still there is the implementation choice to be made even if paradigms do overlap. In the practical world, this choice is still upon the developer/designer. That is what I will emphasize here, the rest is mostly philosophical angel-pinning.
  • I've made a stronger statement than "sharing techniques". Your DoubleDispatchExample implements an entire gamut of techniques in a certain combination. It is the combination, not the individual techniques, that makes it clear you reinvented OO. I don't claim this a bad thing, but it does counter your "code is *either* in tables *or* in objects/classes" argument.
  • What? I don't get it. Either the code-refs are in tables OOOORRRR in OOPL classes (if we put it in both, then we violate OnceAndOnlyOnce).
    • Sigh. When "putting it into a table" is the manner in which we implement "putting it into a class / object", the code-ref will end up (OnceAndOnlyOnce) simultaneously in a physical table and in the logical class/object. Some SmallTalk implementations work this way. So does your DoubleDispatchExample.
    • If we mix physical and logical, we can go both ways. One could say that a class is a logical (crippled) table and that OOP is really TableOrientedProgramming with annoying restrictions. You risk opening the door to EverythingIsEverything?. Implementation-wise, a practical developer in the practical world still has to make a practical choice between OOPL class and DB table.
    • Uh, yes Top. And your relational model is really a crippled basketball. I don't find your argument particularly cogent. In any case, I agree that a developer needs to make a decision for domain data, but that doesn't pit OOP against Relational. It only pits DomainObjects against Relational.
    • Objects are objects, regardless of whether you sub-classify them or not. And, I'm not here for a ParadigmPissingMatch over "better". If the RDBMS did not exist, there would be no choice. The introduction of the RDBMS creates a choice. That should be clear to everyone. With that being said, we'll just have to disagree and let the reader decide for him/herself.
    • [RDBMSes do not introduce a choice between the RelationalModel and object-oriented programming, they introduce a choice between object-oriented DBMSes and relational DBMSes, which is a debate that hasn't been interesting or relevant for at least a decade, if it ever was. The RelationalModel and object-oriented programming have always been complementary; evidence is the fact that many RDBMSes are successfully implemented using object-oriented programming, and their client-side applications are implemented using object-oriented programming.]
      • "Client" is an overloaded word. Please clarify. As far as writing the RDBMS engine in OOPL's, that may be the case, but I'm not sure what this tells us. Writing a RDBMS with another RDBMS doesn't make a lot of sense in most cases.
      • ["Client" = any application that makes use of an RDBMS. I find it curious that you offer "Relational" programming (?) as an alternative to OO programming, yet claim that "writing a RDBMS with another RDBMS doesn't make a lot of sense". How can this be so, if "Relational" programming is an alternative to OO programming?]
      • I mostly comment in the domain of custom biz apps, not systems software. In theory one could use an RDBMS to implement another RDBMS, but for performance reasons its usually not an option. RDBMS are by plan not designed to implement systems software, whereas, C++ is. (Maybe it's possible, but it hasn't been done to my knowledge.)
      • [How do custom biz apps differ from systems software? (I've written both, and see no difference from a programming point of view.)]
      • For one, CPU performance is usually less of an issue. The number of total users per line of code is generally much smaller such that there is less economic pressure to worry about performance and resources. If you sell a product to tens of thousands, then optimization makes a bigger difference. The bottleneck for custom apps tends to be the network, not CPU. Further, the different ways the software will be used is smaller with custom apps. If you make an interpreter, for example, you have no idea what kind of programs people are going to write for it, and thus cannot assume that say lists are used more than arrays or vise verse. But with custom apps you generally know the usage profiles, and thus can skip detailed optimization of many parts. If they have 500 customers today, its a safe bet that they are not going to suddenly have 20k. You wait until it looks like there will be mass growth before optimizing it for mass customers. --top
      • [What relevance does this have from a programming point of view? To me, a choice of OO vs Relational (assuming there is one) is about intended purpose, desired functionality and the like, not performance.]
      • I was speaking from a practical point of view, not a theoretical one. They can all be "written" (emulated) in each other and themselves in theory, but again that doesn't tell us anything interesting. --top
      • [I am writing from a practical point of view as well. Practically, I don't see any benefit to forgoing an OO approach when it is more appropriate than a Relational one, or vice versa. Hence, my view that OO and Relational are complementary rather than competing -- in many cases, both are appropriately used in conjunction. Indeed, that's why much of the current practical and theoretical academic work by Date and Darwen et al. on the RelationalModel and database languages is on reconciling OO and the RelationalModel rather than promoting one over the other.]
    • Hmmm... BadCodeCanBeWrittenInAnyLanguage, Top. Here's what I consider an analogy to our conversation:
      • PopMind: "Relational is very hard to use because everything is in one gigantic table that represents the memory of my system and contains all the procedures and data."
      • TabMind: "Uh... dude... I don't know what to say. There are better ways to organize your data in relational. What you're describing is pretty far removed from how I suggested combining procedural and relational. I've been telling you this all along."
      • PopMind: "Tables are tables, regardless of how you sub-classify them or not. I just don't see how they help; every example I can think of seems broken. I'm not here for a ParadigmPissingMatch over `better`, but I must say I'm disappointed with RDBMS. No matter how I look at it, they just aren't compatible with procedural."
      • I don't know what specific text this is supposed to parody. Is it a complaint about hinting at "better than" issues but not finishing them? I admit I did some of that, but so did you. It may spark a different discussion, that's what wiki's are about.
      • You still don't get it, huh? Then PopMind probably wouldn't get it, either. I'll let that stand for the readers.
      • Okay with me. And if any of you readers out there know what the #@$*! he's talking about, please clue me in.
    • So, Top... dude... I don't know what to say. There are better ways to organize your program in OOP. What you're describing is pretty far removed from how I suggested combining relational and OOP. I've been telling you this all along.

  • From the implementation side, its a slam dunk dichotomy. tables-or-oopl, tables-or-oopl. Wallah! It seems so damned clear to me. Sigh. I'm done with this part of the debate for a while. I'll LetTheReaderDecide for themself. (And if it is "doing OO", for the sake of argument, then "doing OO" in tables is often better than doing it in OOPL, at least by the way my mind works with code and data.)
    • Coordination of OO and Relational puts external data into Relational and internal code into whatever OO implementation language is desired. If there is a dichotomy, you've done nothing to demonstrate it but flap your hands about and say "it's so damned clear to me". Your DoubleDispatchExample isn't evidence against OOP+Relational; it's simply your attempt to avoid OOP by using Procedural+Relational instead, and it was a failure even to avoid OOP in about the same sense as would be using C structures full of function pointers and void* data.
    • As above, one could say that putting it in an OOPL is avoiding TableOrientedProgramming, sticking to static, ugly, hard to read and hard to search OOPL code lacking built-in predicate and set queries/operations. This is degenerating into a tool fight again, which is not what I intended.
      • You'd be disappointed if you think putting code into an RDBMS makes it less static, easier to read, or easier to search. But I share your discomfort with OOP's limitations when it comes to predicate dispatch, CrossCuttingConcerns like concurrency and logging, etc. Of course, your DoubleDispatchExample would share those particular limitations.
      • But be easier to add them. OO will do poorly under a many-to-many classification system. But, that's getting off-topic.
      • Hmmm? OO does poorly when dealing with DomainObjects, which might need a many-to-many classification system. OTOH, you won't have any DomainObjects if you put external data into Relational and use OO only for computation objects (and occasional value-objects to represent commands/messages)... which, if you were paying attention, is what I already described.

    • Further, some say that OO excludes tables because they lack encapsulation. OO encapsulation restricts access to accessors. Relational has no direct equivalent, usually using set-based security "groups" instead. In OO you tend to "add" access while in relational you tend to subtract it. (RelationalBreaksEncapsulation)
      • Encapsulation is useless for DomainObjects (see ObjectVsModel). There isn't any value in encapsulating them. Encapsulation is only valuable for internal black-box stuff. A program takes input, processes that input, and produces output; encapsulation is only valuable for the 'process' step. This all fits with what I've already told you: one coordinates OO with Relational by putting external data into relational and uses OO to build and configure code that processes it.
      • Whether encapsulation is "good" is another issue. If encapsulation is removed, then it is "less OO".
      • "Less OO" - I'll agree. Putting domain data into relational tables instead of DomainObjects is "less OO". But, then, the question isn't whether we're moving away from "pure OO", but whether OOP is compatible with relational in the same sense that procedural is compatible with relational.

      • "Compatible" was not the word I used, but rather "fight over territory". You seem to be agreeing by suggesting a choice here: "Putting ... into relational tables instead of ... objects" (Emph. added). Thus, a choice exists, creating a design battle over territory. Again, it seems blatantly clear, but you don't seem to being seeing this the same way. This is getting frustrating.
        • By analogy, TopMind, you could say that Procedural competes with Relational in that same sense because one can "Put domain data into tables instead of procedures." Is this not blatantly clear? Unless you also assert that procedural fights over territory with relational, the reasoning for your complaint about OOP fighting over territory with relational will be logically inconsistent.
        • PageAnchor Overlap_57: In an absolute sense, you are right. But in an absolute sense, everything can emulate everything, just about. We are thus dealing with tendencies. Maybe one can use reg-ex's as an array (per nearby example), but it is not normal practice. The level of overlap in usage is continuous for any two features, some more than others. Just about everything indeed *does* fight over territory with everything to varying degrees. Lists and indexed arrays tend to have a high overlap, but not arrays and reg-ex's, for example. One is more likely to stop and ponder lists versus indexed arrays during the design phase much more often than they are to stop and ponder using arrays or reg-ex's, I think we can both agree. OO and relational tend to have a higher overlap in my observation of their usage in practice. For example, should "employees" could be modeled as objects, or as relational tables. To avoid violating OnceAndOnlyOnce (a MirrorModel), we ideally don't want employee-related attributes to be cataloged and tracked under both relational and OOP.
        • Okay, I'll happily agree that "fights over territory" is a matter of degree. Now you've just got to prove this relative "higher score" claim, then I'll agree with you. Go on...
        • I honestly don't know how to measure that in an objective way. I can only compare specific examples to alternative designs, such as the printer driver example and PayrollExample. Most medium-to-large OOP code bases I've seen had places where tables could have been used to store attributes and/or behavioral references instead. If you feed me typical OO code, I can probably find lots of places for such. Apps that use OO to model/store/track tons of attributes and tons of relationships are candidates for such.
        • I've no disagreement that 'Table' with automated multi-indexing and support for joins and queries would be a useful standard-library object, but this is (to me) only further evidence that Relational and OOP are complementary and mutually beneficial, especially given the degree of effort OOPers go through when a table would be the best option. Hardly seems like fighting over territory to me. Pointing out how many places OOP would be readily enhanced by Relational seems, rather, the exact opposite of a fight over territory.
        • If you did such, you would have a kind of RDBMS. It would be less OO because encapsulation would be broken. This came up before when we tried to merge them to get the best of both worlds. Encapsulation is the primary difference that prevents a clean merge. Inheritance also creates confusion because then we have a choice of using sets or tree-based pathing. But this is the smaller of the two buggaboos. Further, for languages that don't allow multiple inheritance, sub-classing used for making a class relational reduces the ability to use it for other OO purposes since inheritance is a single slot. Interface inheritance is less powerful.
        • [A 'Table' class is merely a container. It is no more an RDBMS than, say, a generic linked list is "a kind of RDBMS". Nor does it break encapsulation, any more than any other container does, i.e., not at all. Inheritance doesn't create confusion, but may certainly be inappropriate in cases where it is... Inappropriate. However, OO is most appropriately used to create computational objects rather than domain objects (unless, of course, you're creating a simulation). As such, inheritance hierarchies are typically invariant and conceptually clear. Please do not confuse OO programming with general-purpose OO databases. They are very, very different beasts.]
        • If you put all those doo-dads you listed, it would indeed be a low-end RDBMS, or perhaps a RAM-only, and/or embedded RDBMS. As far as "appropriately used", while I tend to agree with you on that, remember that your view of what is "good OO" is not universal. I will not use your view of "good OO" as the compare base. My target sample set is actual code "out there", or a close approximation. But it is true that the degree of overlap will depend on the style of OO being compared. That's just life.
        • [I see no mention of ACID-compliant persistence or stand-alone capability, hence the described 'Table' class is not a RDBMS by any of the accepted definitions of "RDBMS". An implementation of the RelationalModel is not necessarily a DBMS! My view of "good OO" is indeed not universal, but it is generally accepted among experienced OO developers. Most textbook and popular OO book authors (i.e., the ones who present simplistic inheritance hierarchies of zoo creatures and geometric shapes), by the way, are experienced writers and journalists, not OO developers.]
        • Okay, I should have said "relational", but don't want to get into a DatabaseDefinition battle here.
        • Without a way to survey, it's hard to verify your claim about how experience changes OO developers. It's a kind of NoTrueScotsman debate/issue. We'll just state our experience and observations, and let's leave it at that.

      • As a simpler example, indexed arrays and lists often fight over territory because one can often be used in place of the other. A developer has to make a choice to use arrays or lists when they want fairly simply collections to iterate over. If a language only offered arrays, then there is no choice: arrays are *it* (maybe files, but that's not part of this example). The arrays are not going to fight over territory with, say, a regular-expression engine because they solve very different problems most of the time.
        • OOP is not used to persist or maintain domain data... at least not 'most of the time'. I'm curious as to what makes you believe and insist otherwise.
        • In the printer driver example it sure is.
        • Disagree. The printer driver example does not have the printer drivers persisting or maintaining information about printer configurations.
        • Okay, we need to see more of the production code-base to know. It's like looking at half of a schema.

        • But in general the overlap depends on the developer's style. In PayrollExample it is because Bob uses classes and objects where I use a ControlTable to describe parts of paychecks.
        • "Overlap depends on the developer's style" derives from "BadCodeCanBeWrittenInAnyLanguage" and isn't particularly interesting or useful. I'm certain I could write a relational example that you'd be ashamed to see evangelized among the benefits of Relational. RobertCecilMartin can do the same for OOP. (Not that I care about OOP. I understand it, I use it, I dislike it, and I'd like to kill it off with a combination of LogicProgramming, SubscribeByQuery?, TransactionalActorModel, and FlowBasedProgramming.)
        • I'm generally talking about code I see out in the field. We can use textbook examples for a set of samples. Ideally, we'd survey wider, but don't have the resources. If you mean a specific brand of OO or relational, then that changes things obviously.
        • That's fair. But I'm going to ask that, if you have all these exceptions to them, you be careful about how you word your claims. Instead of saying: "OOP and Relational are a strong dichotomy", say, perhaps, "There is a lot of OO code out there that would have been easier to develop and maintain if written in relational." I'd be especially happy if (instead of being indiscriminate) you blasted 'DomainObjects' and 'BusinessObjects' at every opportunity. DomainObjects are the the primary source of your various complaints about OO, and are a source of its greatest fallacies - people who use them end up ReinventingTheDatabaseInApplication and creating domain simulators even when doing so doesn't make sense. (With a little more precision in your assertions, you won't rile up us SystemProgramming guys who have been usefully combining relational and OO for years. At the moment I feel like (by analogy) you've been saying "tables are tables" then blasting all uses of relational because some people don't know how to write a schema. Only, being a RelationalWeenie, you're attacking OO instead of relational.)
        • That'd be too big for a title :-) Note that even for "computational space" objects, relational/RDBMS can be used for that also. It's just a less contentious area, but a choice still exists there. We could build GUI engines using tables, for example. I'm not commenting on which is "better" here, but merely that one is faced with a choice whenever data structures or things similar to them are involved.
        • Too big a title? From someone who just wrote "AreOoAndRelationalOrthogonalDiscussionThree"? Heh. ;) I agree that one 'can' shove "computational space" objects into an RDBMS. But the 'global' nature of RDBMS tends to handle "computational space" objects (which encapsulate subprogram behavior) just as poorly as OOP handles DomainObjects (which describe 'global' real-world data). The reason is a fundamental duality, described in ObjectVsModel. One generally cannot support even the class of FunctorObjects in RDBMS without considerable effort: one option is reinventing OOP and heavily using scripts (which pretty much renders useless the query and data manipulation benefits of RDBMS: scripts, like other large strings and binary data, are generally opaque to such efforts). Another option is exposing the full runtime engine in the RDBMS (which is doable, and offers better queries and manipulation than scripts, but now must reinvent an entire programming language). PickTheRightToolForTheJob, and the tools we readily have available, demands we combine approaches if we wish to support both halves of the problem - both domain data and runtime ConfigurableModularity of the application. Still, given growing support for things like LanguageIntegratedQuery? and LogicProgramming, I suspect that the FutureOfProgrammingLanguages will support relations and relational operations within 'application' languages (though I hope to achieve NoApplication at some point in that future, too). And, similarly, the relations within said language will support the full 'application' language type system and functions for queries, making complex values readily accessible to queries and manipulations. (And it was good.)
        • The original topic was "AreOoAndRelationalOrthogonal?". It merely grew over time due to expansion and a naming EditWar. My point was that topic names are not meant to be legal statements with all the necessary disclaimers in place. Scope limiters and disclaimers belong *inside* the topic.
          • I believe you should be prepared to defend the topic title, as it stands, if it makes a statement. This is because references to that PageName from other pages will not be listing the disclaimers, and the page will likely be applied even in cases where the disclaimer should apply. So, while I agree you should keep the scope limitations and disclaimers inside the page, you should avoid making a bold statement with the topic title if you're going to have any disclaimers or any scope limitations that aren't obvious to most readers from just the title.
          • We'll just have to AgreeToDisagree on that one. Titles should give a good idea what the topic is about, but should not carry the entire load if it makes them too long.
          • I didn't suggest making titles "too long", Top. I suggested "avoid making a bold statement" if there are going to be disclaimers. Is your creativity so lacking that you can't imagine how to avoid making a bold statement without making a title "too long"?
          • The title is a question, not a statement. Bold question?

        • As far as the wisdom of using tables for "computational space", it does not have to always be the wise choice to still be a choice. I am merely pointing out that the choice exists, not that its always the best. As far as scripting, I am a scripting fan so I don't see that as a problem. Plus once one gets used to declarative/attribute-oriented programming, the need for scripts or function references *in* the table itself often diminishes. One ends up using mostly feature selectors instead. (Although I do store SQL predicates in tables somewhat often.) People just are not used to it to reduce the need via experience. Translating an OO design one-for-one, such as a StrategyPattern, will often not produce very good results. But, that's another story. --top
          • I have no problem with scripting, but (at least in my work) it's worth knowing the properties a scripted system will have. I'll note that 'feature selectors' push code back into the regular codebase but essentially aim to dynamically configure that code based on a set of features - this is an approach that is quite amenable to the ConfigurableModularity that OO offers.
          • Regarding 'choice': Among the Python philosophies is "there should be one, and preferably only one, obvious way to do it." Unwise choices are okay, so long as they are not obvious or are obviously unwise. It's when the unwise choices look 'just as good' as the wise choices that programmers will choose paths that will run them into problems down the line.

In any case, as noted above the DoubleDispatchExample does not serve as evidence or support for the idea that OO competes with relational.

---

JanuaryZeroNine CategoryDatabase