(Moved from ArgumentsAgainstOop)
Linus Torvalds allegedly said:
"I personally believe that Visual Basic did more for programming than Object-Oriented Languages did. Yet people laugh at VB and say its a bad language, and theyve been talking about OO languages for decades. And no, Visual Basic wasnt a great language, but I think the easy database interfaces in VB were fundamentally more important."
Great. A speculative ArgumentFromAuthority. Just what we need around here.
Aside from the fact that I don't have any reason to believe that Linus Torvalds has spent any time studying the effects of VB and OOPLs, there's also the issue that OOPLs have influenced VB for quite some time. In fact, (if I remember the events correctly) VB's easy database interfaces were enabled by OOPLs' influence on VB.
Perhaps he meant "bound data controls". But, being built with OOP under the hood may be a different issue than app developers using OOP themselves (making their own classes). This is possibly related to OopNotForDomainModeling.
I was referring to the interface itself. For this argument, it's not relevant whether OO was used under the hood, as any of the major paradigms would be capable of implementing the interface. What's relevant is that the design of the interface was influenced by OOPLs. By the way, I see no need to slice and dice what he said until I find something palatable. He said what he said, and unless he decides to correct it (or otherwise indicates that he didn't mean it), I'm going to act like he meant what he said.
There are multiple interpretations to his statement. And whether "OOP" is also a GUI technique (has a GUI counter-part) is perhaps debatable without clear rules or agreement on how to tell which GUI elements or behaviors are "OO" and which are not. Is there also a "functional GUI" (FP)?
Note that using "species" as a divider is perhaps problematic. A chihuahua is not likely to mate with a wolf due to the size difference. Does this mean the chihuahua is a different species than the wolf? Larger dogs can and do mate with wolves (which dogs are closely related to).
You didn't just slice and dice my comments, you pureed them. Why don't you try reading what I said and responding to that, instead of bringing in this GUI and species stuff out of left field.
I've read your statements multiple times. If I misinterpreted them, I assure you it was not on purpose.
To answer your questions, you look at the properties. You don't need clear rules, just clear enough, and you don't need agreement at all unless you want to have agreement about the conclusions. The question about the wolves depends on what type of wolf you are talking about. Ethiopian wolves (Canus simensis) are not the same species as chihuahuas (Canus Lupus). Grey wolves, on the other hand, are. I should note that species aren't just about being able to mate. For most creatures, that distinction doesn't even make sense as they reproduce asexually. So while for most larger animals it's a good rule of thumb, it's not the defining characteristic. Therefore, you shouldn't draw too many conclusions based off of it.
As far as "properties", lots of things have properties, or their equivalent. Each column in a database record can be viewed as a "property", for example. (I assume you meant "object properties", but I cannot rule out alternative contexts.)
As far as "species", animals that primarily reproduce asexually as not classified by "species" (TTBOMN). But rather "strain".
Everything has properties, why should that be a problem? And everything that we consider living is classified by species. Two examples of species that reproduce asexually are Pelomyxa palustris and Amoeba proteus. Strains are an even finer grained classification than species.
You are correct, but it appears that a rather arbitrary line has been drawn for asexual organisms, such as "X percent of DNA is the same", and some biologists still complain about that because it's possible for a very small percent to make very large "outer" difference.
{I must admit to some confusion: what does this 'species' stuff have to do with OOP or ArgumentsAgainstOop?}
Hmmm. There appears to have been some unobserved editing going on. The paragraph that sparked the species issue is no longer here.
[I've been following this section since the beginning, and there never was anything to do with species. As one respondent wrote, you were "bringing in this ... species stuff out of left field," and your comment that "using 'species' as a divider is perhaps problematic," appears to be the first mention of it. Looks like you mixed up this thread with something else.]
Your excess griping makes it hard to know when you gripes are real. "GUI" was NOT out of left field (unless you meant something different by "interface".) As far as "species", time to put on the memory-lane hat...
{Even a casual observation of context makes it clear that "interface" referred to "VB's easy database interfaces" (mentioned prior) and what "app-developers use themselves" being influenced by OOP as opposed to "OOP under-the-hood". So, yes, mention of "GUI" was out of left field. And unless a gripe is in jest, it's a real gripe by nature, so your sentence about 'excess griping' makes little sense to me ;-).}
"Database interface" is not clear and could mean the DAO/ADO [DataAccessObject, ActivexDataObject] API's, the GUI, or a combo, such as "bound" controls.
{It is my impression that you seek a DifferenceThatMakesNoDifference. If the shoe fits, wear it. VisualBasic's support for DAO/ADO API's are certainly OOPL influenced, and so are its GUI development facilities. Indeed, VB as a whole is strongly OOPL influenced (albeit dynamic) compared to other Basics I've used; there are many features involving a great deal of dotted-path access and polymorphic overloading. Even separate 'pages' of code are associated with objects and methods in VB's IDE. (As a caveat, my experience is dated: I used various forms of BASIC only circa 1991-1999, and VB only during 1996-1998 with a painful 3.5" floppy transition from 5.0 to 6.0.) Of course, the statement by LinusTorvalds might be even more dated. I don't know from which version of VB his impressions derive. But I strongly suspect the earlier author referred to DAO/ADO, since that is the most direct "interface" by which VB programmers access databases.}
- Again, what does an OO GUI look like ("GUI development facilities") and how are you measuring OO-ness of visuals?
- {It seems there's a misunderstanding... perhaps you're reading "OO-GUI development facilities" whereas I'm reading "OO GUI-development-facilities"? Either way, it's unclear to me how OO-ness of visuals is relevant. OO GUI-development-facilities can be recognized by such features as buttons having 'onClick' methods and setters for button text and so on. OO IntegratedDevelopmentEnvironments can be recognized by how the associate pages of code (again, onClick methods being a good example) with buttons on given form classes which may later be instantiated or shown/hidden. SmalltalkLanguage has a long history of OO-style IDEs for comparison.}
- I fail to see how the dash matters.
- {And I fail to see how "OO-ness of visuals" matters. I referred to OO development facilities for GUIs, not development facilities for GUIs with OO-visuals.}
- And, I do not view events as an inherently OOP concept. And setters/getters are not inherently OOP either.
- {Concepts aren't "owned" by paradigms; rather, paradigms involve a set of concepts. See WhatIsaParadigm and perhaps an excellent overview: <http://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf>. You have OOP if you pass messages to references - i.e. to a particular button - which can respond in a manner not decided by the caller. Similarly for setters/getters. Sure, procedural could wrap a setter or getter, but not in a manner selected by the callee rather than the caller.}
- They [events] are perhaps more FP-ish than OOP.
- {I don't see how you could consider events to be FP-ish: 'pure' FP languages don't allow for "events", so they surely must be other-than FP-ish. I'd consider DataflowProgramming and EventDrivenProgramming to be their own paradigms (with forms of the latter including ComplexEventProcessing), but VB isn't very much EventDrivenProgramming; it integrates events only on the outer edge, and routes those events to objects associated with GUI elements. (This is as opposed to sending all events to a grand-central script which must process every event - which is the procedural approach.)}
- And we already discussed who "properties" belongs to above.
- {Your comment above about properties was an erroneous conflation on your part of 'properties' with 'object attributes', whereas the only sensible interpretation is that the author spoke of distinguishable system features. Further, this comment of yours is a lie: you DID NOT discuss who properties "belong to" above. You only suggested that there are many things one might call 'properties'; ownership was never involved. I'm not sure how you think ownership of properties is relevant here, either.}
- Existing OOP languages and API's simply make them (overly) apparent out of industry habit. Some OOP proponents argue a good case that "true" OOP would make no external distinction between methods and attributes. But this will takes into NobodyAgreesOnWhatOoIs.
- {NobodyAgreesOnExactlyWhatOoIs, true; there is argument over whether inheritance and such are relevant, for example, and some argument as to whether methods ought have access to 'self' reference. But the fundamental properties - references that can be stored in variables, ability to send messages to or call methods on these references, ability for the callee to react in a manner not determined by the caller - are well accepted as being the properties that can be used to claim one is using OOP techniques even in a multi-paradigm or non-OOPL language.}
- But words such as "variable", "reference", "callee", "method", etc. can be interpreted many different ways, and tend to be language- and viewpoint-specific. And extrapolating all that to IDE's from languages is another layer of term translation problems.
- {You imply that this potential for equivocation has in practice been a significant point of contention and misunderstanding, but I do not believe it has been. And extrapolating to IDEs isn't merely theoretical: we have examples of OO IDEs - SqueakSmalltalk, OpenCroquet, VisualAge, etc.}
- On the language side, yes. But that says little or nothing about the GUI builder.
- {Those are GUI builders, too.}
- And we'd have to compare to a non-OO-GUI builder to test our working definition of OO-oriented GUI builders.
- {There are plenty to compare against: DisplayPostscript, pure HTML (ignoring DocumentObjectModel), and more. I hate working with GUIs, but I only know that because I've implemented a few - not all of them OOP. I wrote an Asteroids game in BASIC at age ~16. It was very procedural, but didn't use the mouse (I tend to think of "GUI" as involving a pointer-device rather than simply being graphical feedback).}
- If we compare non-GUI to GUI, then the GUI existence will likely overwhelm any differences caused by the paradigm. In other words, we still need a comparable example GUI/IDE.
- {Perhaps we could avoid some confusion by referring to 'visual IDE' when we're talking about the IDE? Anyhow, WysiWyg editors are available for HTML. If you consider MicrosoftExcel spreadsheet apps as a form of GUI (not too unreasonable), then you also have an example of a DataflowProgramming visual IDE for developing GUIs - elements are defined in terms of what they should contain based on other global elements (rather than how they should react to events, which is OOP style). There are others available for comparisons.}
- Almost none of the "typical" features one finds in a GUI builder are exclusively OO, if we ignore the language issues. Let's revisit specifics:
- Events such as "onClick": EventDrivenProgramming is as least as much functional as it is OO, if not more.
- {"onClick" is a method, not an event ("click" is the event). It is OO because the message is routed to a particular button or window object, and the appropriate 'onClick' behavior executes polymorphically. EventDrivenProgramming can be done procedurally (I've done it), but it means routing all click events (no matter where the click) to the same procedure along with x,y coordinates and such. EventDrivenProgramming is not functional, not even a little bit; it takes impure functions (aka 'procedures') to do anything at all useful with an event.}
- I'm not sure it is a method in VB. VB is (was? I used up to 6.0) weird that way. And even if it did generate a clear OOP method, that's merely a to-language interface issue. It wouldn't change the way I interacted with the IDE; for when I opened the event subroutine, or whatever the hell it's called, I didn't need to know or care whether it was part of a "class" or not. I didn't use "class" features, at least app-language-wise.
- {Under-the-hood, it was a procedure - something like 'SUB Button_A_OnClick'. (Similarly, methods are implemented as procedures under-the-hood in almost every OO language.) But, as you say, it's "the way you interact with the IDE" that matters to the estimation of OOP. And how you interact with the IDE is this: you click on the 'button object', you ask to edit its 'onClick' behavior, and it opens a page with just that code. So, by the standards you are using, it is OOP.}
- So anything that associates a segment of code with a domain noun is OOP? I don't see that as being more OO than functional. Plus, a CASE or IF statement can do the same: "if user selected noun_3 then do procedure p3".
- {It is the implicit routing of messages and automatic association of code to program objects (not "domain" objects, excepting insofar as the domain objects are represented as program objects as common to GUI, ADO, DAO) that make it OO from a programmer's perspective. Related: NygaardClassification. You cannot do the same with a CASE or IF statement because avoiding the explicit routing for the CASE or IF statement is pretty much what OOP polymorphism is "doing". A procedural GUI would require you to explicitly go in and add an extra case or if-statement to handle the new button, supposing you didn't just re-implement the OOP style (procedural and OOP being relatively close in terms of shared concepts makes such re-implementation easy given just a couple extra features: procedure references and long-lived data references). (Also, I believe you shouldn't claim something is "functional" unless it can be said to be true of "pure functional". Impure functional languages support a random mix of programming styles - functional + procedural + OOP too if they have lexical closures with mutable variables. And they support each style 'badly' in terms of optimizability, scalability, predictable composition, and security.)}
- Please clarify "automatic". We don't know what VB does under the hood. It may be generating CASE lists for all we know. After all, it's generating a subroutine and it's name, so we know it's capable of that kind of thing. We could make a VB clone that does use CASE under the hood for sure and the user couldn't tell. But that's an implementation issue so is not an app developer's concern. It won't change what the IDE user sees.
- {That's what "automatic" means: VB is generating such lists without programmer intervention. How such things are 'compiled' under-the-hood is, as you note, irrelevant. It's still OOP to the IDE-user for the reasons described above. If the IDE-users were responsible for routing the calls explicitly, that would be procedural: that's what you do in procedural languages - explicitly route calls to structured subroutines using conditional statements based on arguments and global variables.}
- What is going under the hood? How do you know?
- {That is not a relevant question. As you're so fond of saying, VB could be training gerbils with sharp pencils under the hood. But the programmers didn't need to route the event to the correct method, and the programmers simply assigned a method to the abstract button object, and the behavior of the button instance was polymorphic to the programmers. That's OOP. Why would it matter what is going on under the hood? It's been over a decade since I used VB 6.0. (If you are genuinely curious about the implementation, you'll need to look it up yourself - I no longer care. I would guess that it compiles into a set of intersection tests in a big loop, finds the right button object, and jumps to a table entry... but that guess is only based on how I'd first approach it knowing about VB's ability to move buttons around or create new button instances at runtime.)}
- I was referencing what you said. You are the one who keeps sliding back to under the hood stuff.
- {You asked a question about what was under-the-hood, so I answered, but I have never once wavered on the point that it's irrelevant.}
- Please clarify "the behavior of the button instance was polymorphic to the programmers". How does one objectively and unambiguously measure polymorphism happening on the screen? (Without creating a personal mental model of the internal guts.)
- {It's "polymorphic to the programmers" in the same sense that any OOP virtual method is polymorphic: the method called is determined by which object is clicked, as opposed to being determined globally for all clicks.}
- That's very very general. My "off" button on my lamp does the same thing. If I emulate the lamp on the my PC it's suddenly very OO?
- {No, but the emulation-program might be OOP. I've said earlier that I'm talking about VB's Object Oriented development utilities for GUIs, NOT development utilities for Object Oriented GUI's. The development is OO-influenced. For the visuals, it simply isn't a relevant question. Your question about "polymorphism happening on the screen" strikes me as irrelevant semantic gibberish, so I ignored it.}
- I give up. I don't know what the hell you are talking about. Sigh.
- A functional approach may resemble: eval("sub_" & thisEventName & "_" & thisWidgetName)
- {In what way does that resemble a functional approach?}
- What paradigm would you classify it as?
- {To me, the 'eval' statement suggests runtime reflection and inclusion of an interpreter, which simply isn't a paradigm at all (or could be part of any paradigm). And the fact that it's presumably evaluating the name of a subroutine - presumably to execute it for side-effects - suggests it would be a procedural or imperative language. But I wasn't asking what I think. I asked you: In what way does that resemble a functional approach?}
- "Can be implemented as a method" and "is a method" are not the same thing. Frankly, I don't know how VB events are implemented under the hood and shouldn't need to care as an app developer.
- {Correct. And onClick "is a method". It is implemented as such at the programmer-VisualBasic interface: you select a button object, choose to edit its on-click behavior, and clicks are routed to that behavior automatically. That's editing a method of an object. That's OOP.}
- That's not what "OOP is about". It may be something OOP can do, but is not exclusively OOP. It can be implemented in almost every paradigm perfectly well (assuming a non-restrictive language).
- {Editing 'methods' of 'objects' is, as far as I can tell, unique to OOP. Which other paradigm does this? Reactive certainly doesn't. Procedural edits procedures, and functional edits functions, but these paradigms do so in terms of 'call-sites'; all 'routing' of behavior is up to the programmer, and so procedural design requires explicitly injecting a call. OO, and VB, edit behavior of objects - at the point of reaction rather than action. And why are you waving that silly TuringEquivalence? flag again? Put it down.}
- For one, they are not methods, but subroutines. And it wouldn't matter even if they were: the IDE user didn't treat them as part of classes, but merely as subroutines. Their relationship with the rest of the code-base was generally hidden, or at least down-played.
- {They are 'methods' because they are associated with which object receives the event. Sure, they're implemented as subroutines - under the hood - but the IDE and language uses these subroutines same as any OO language uses methods - where it matters, at the surface. And "classes" are optional for OO, but VB's GUI development does have a few: button, form, list, textbox, etc. VB itself isn't an OOPL, of course - limited ability to create and destroy objects, no extensible objects or user-defined classes, etc. I recall creating a video-game in VB with ships, lasers, battlestars, missiles, and bullets with arbitrary properties (color, position, flight pattern), though, so I might be forgetting something. (I was still in High School... nothing better to do than create stupidly addictive games.)}
- I find your argument weak. You are being very wide and loose about what OOP "is". Until we settle on unambigious characteristics for what's OOP and what's not, this cannot be settled.
- {I do not believe I have been "wide and loose" about OOP - you just have this vague notion in your head that OOP includes 'everything', despite your inability to demonstrate how it includes a panoply of languages and paradigms. Regardless, I am allowed quite a bit of leeway when discussing 'OOP-influence' since that doesn't require proving full-OOP-ness. It should even be expected, given that VB was invented twenty years after OOP and has been through over six major revisions. Dot-based access to 'properties' and the ability to call methods like 'list.AddItem? Item', and the ability in the IDE to create 'new forms', add 'new buttons', then select button-objects and immediately open a window to manipulate what happens when the button receives the 'click' event without any need at all to drop into procedural code and explicitly figure out where to inject the subroutine - these things are circumstantial evidence of OOP influence, but there is a great deal of it and it paints a pretty strong picture. Given all this, I suspect your skepticism is motivated by something other than impartial reasoning. What emotional reasons make you want to reject the notion that VB's GUI-development and ADO/DAO are OOP influenced?}
- Property sheets: Everything has "properties", but they may be called fields, rows, columns, elements of a map, etc. A property sheet is pretty much a CrudScreen for widget info.
- {Property sheets for "things"? Where did the "thing" come from if it is not a referenced object, I wonder?}
- It could be an entity or a record or a smart gerbil with a pencil or whatnot. That's an implementation issue.
- {That's a rather useless reply, TopMind? How do I, as a programmer, reference this 'entity' or 'record' or 'smart gerbil with a pencil' such that I can declare it to be the source of properties for my property-sheet?}
- Drag-and-drop wigdets: I see no connection.
- {No connection to OO? Well, consider that a pure procedural drag+drop consists of a mouse down, a movement, and a mouse up, along with pattern-detection - and all you get are xy coordinates. You can't get a reference to the "object" you "clicked on" or the "object" you "dropped on" because those would not be pure procedural, though you are free to re-implement OOP in procedural to associate events with particular buttons (after you perform the intersection tests...).}
- EverythingIsEverything? if we play enough vocab indirection. Every sentence I write will probably have a noun, and if you say every noun is an object, then everything with nouns is OOP. Sure, if your def of OO is wide enough, then VB's GUI IDE is indeed OOP. But so is my watch and my TV and my Commodore-64.
- {I'm not playing word-games, TopMind. You're free to implement some procedural mouse and keyboard handlers if you're skeptical that there is a meaningful difference; they're pretty much the default when working with OpenGL UIs. Treating widgets as objects, automatically routing 'events' to the correct 'object' (click to the correct button, keystrokes to the correct text box, etc.) - these things are significant (especially when they get in the way). The difference between OOPLs and Procedural is just a little bit of automated computation under-the-hood, and it is similar here. The OO influence on VB's GUI development utilities is obvious to anyone who has used other GUI development methodologies. Just as clearly, VB itself is not an OOPL, despite its occasional toe into OO-ness with ADO/DAO and such.}
- If it's "obvious", then please find an obvious way to demonstrate it true. I shouldn't be expected to accept argument-by-vague-notion. There may be some underlying bias in that VB used terminology borrowed from OOP in it's IDE. This made one think of it in terms of OOP. But that's not the only metaphor in town. -t
- {Which 'terminology' do you believe was borrowed? Or are you just taking shots in the dark, now? Anyhow, you have an agenda in maintaining your own ignorance ("I see no connection") and you dismiss explanations and examples of procedural drag+drop as "argument-by-vague-notion". I can extrapolate the rest of this conversation from there.}
- "Methods" and "Properties", at least in the Help files that come with it. And don't confuse your poor articulation skills for my ignorance.
- {Can you point me to the documentation using "Methods"? Or are you just betting there is some? And to defend "I see no connection" only requires closing your eyes and keeping them closed. That's an agenda to defend ignorance - and is very difficult to confuse with poor articulation on my part.}
- If I can supply a screen-shot, will you apologize for your rude presumptious guilty-until-proven-innocent accusations? Otherwise, fuck off.
- {Sure, I'll apologize for the 'shooting in the dark' comment if you supply and host screenshot evidence of OOP influence on VisualBasic.}
Yes, I'm referring to DAO/ADO. I assumed that LinusTorvalds was also referring to it, since that's really the only part of VB that I can think of that qualifies as "easy database interfaces", and, unlike Top, I'm not willing to change what he said to suit myself. If he said, "easy database interfaces", I'm going to assume that he's talking about the interface to the DB, not the human computer one. Now, if he wants to make a correction....
DAO/ADO are convoluted crap in my opinion. Scriptish API's that stick a record into an associated array are generally friendlier and simpler. Anyhow, we have at least 4 candidate interpretations: API's, boundness, IDE, and GUI widgets. (VBA's integration with MS-Access could also be part of this. We cannot rule out VBA in Access.) And we have insufficient info to know which one he was talking about, or a combination. If you know how to read minds, I applaud your ability. But, us mortals don't have that ability.
Also, many open-source and Linux/Unix-based tool have not been very database-friendly because they assume one will be processing delimited text files instead of using DB queries. Perl is known for such (see GrepVsDatabase). I suspect this has a lot to do with Linus's impressions.
Top, if you weren't sure which interface I was referring to, you should have asked instead of making random responses. (And it still doesn't explain why you brought species into this thing). In addition, I hardly think that one gripe qualifies as excessive, especially when the gripe is justified. After all, what do species have to do with ArgumentsAgainstOop?
With regard to the species thing, it appears I either mixed up topics (mis-posted replies), or somebody edited out the original paragraph. I've yet to solve that mystery. As far as VB interface, I don't see anything significantly wrong with my response. I stated my assumption as an assumption. I'm inclined to blame your odd writing style, but I can accept the fact that sometimes two styles just don't jell.
[Regarding the species thing, there is no mystery. You have mixed-up topics or mis-posted a reply, because there never was an "original paragraph" to edit out.]
That's rather presumptuous. How could you quickly rule out the possibility that I didn't accidentally paste a reply from another topic into this one by mistake? You'd have to read all 50,000 or so titles here to make sure none match. You tend to assume the worst: That I randomly hallucinated a thread. Stop pretending you are above mortals; you didn't read no fricken 50k titles in 1 day. (I suppose one could Google for "species" on C2, but even that doesn't rule out misspellings of it.)
By the way, it's possible it's tied to the bottom of the AdVerecundiam topic.
[Mistakenly pasting a reply from another topic is precisely what I meant by "mis-posted a reply". It appears we (or, more accurately, you) are in violent agreement.]
Why did you say "there is no mystery" then?
[Because it's not mysterious. Mis-posted reply or mixed-up topics is the explanation. There was no mysterious "original paragraph" about which there was some mystery. I wrote "[y]ou have ... mis-posted a reply", you wrote that you might have "accidentally past[ed] a reply from another topic", hence we have violent agreement. Dig?]
So what you meant is, "there is no mystery that directly involves *this* topic". (To me, the original context is a mystery. The location of the starting point doesn't impact the magnitude of the mystery much. An orphan is an orphan.)
Anyhow, I have no problem with removing the species-oriented text of this topic. Any qualms on your part?
[None at all. Remove freely.]
Or how about to LimitsOfHierarchiesInBiology?
[I doubt it's worth keeping at all.]
It gives some examples of why classification is a difficult subject. Classification based on "greater than N% the same" is an intellectually stimulating idea, and may provide insults into other domains that struggle with classification.
For reference, my working definition of OOP is the use of maps (dictionaries) that frequently store pointers to functions, functions, and pointers to other maps, as well as values. And, perhaps with support for "parent" reference if "clone" inheritance is not used. The "map" may be static or dynamic, depending on the language. --top
{Methinks you conflate OOP and OODB.}
How so? OODB's generally don't store or reference "behavior".
{That is true. But OOP deprecates accessing objects as 'data storage' (maps/dictionaries) even a little bit, and 'pure' OOP tends to forbid it entirely (i.e. attribute accesses becomes implicit call to getter-methods and subject to override). Objects are not merely records to peruse and from which you can grab function-pointers and values. The storage access-style is very strongly OODB. The fact that it's storing 'behavior' (not common to OODB, as you say) makes me think you conflate the two.}
An "interface" version of the above would be "map of interfaces". But there's something missing from it that I cannot put my finger on yet. Perhaps "map of interfaces and/or references to other such maps". Anyhow, I invite you to submit or reference a working def also. Either way, OOP is some form of "glorified maps".
{That question makes me wonder: why do you even bother providing your 'working definition of OOP' in this topic? We have better topics for that, such as DefinitionsForOo.}
I believe we must settle on a working definition(s), or at least be clear which one(s) we are using in order to communicate effectively.
{(1) Where exactly, in this page, would your working definition be useful? (2) What is the benefit of introducing the working definition at the bottom of this page? Would it not be wiser to add it to DefinitionsForOo then reference it with a PageAnchor? (3) Using a working-definition is risky, since your working definition for OOP is (a) unlikely to be the same as Linus Torvald's, (b) and likely to allow StrawMan arguments against your 'definition' that aren't meaningful in the greater context of OOP.}
If one dances between elements of all the candidate definitions, the ensuing dialog would be quite messy (even more than it already is). Everything in the world probably fits at least one listed in DefinitionsForOo. Definitions usually must be falsifiable ("this is not an X") to be useful. If it fits at least one definition, and that makes it "OO", then the application of def is not falsifiable.
{There are dozens of paradigms for which a fit against any one of the DefinitionsForOo would need be terribly convoluted. Look into term-rewrite systems (Maude, OBJ), logic programming (Mercury, Datalog), constraint programming, functional reactive programming, dataflow programming, pure functional programming, SnuspLanguage, rules-based programming, etc. You make what I believe to be a ludicrous claim - that 'everything in the world' fits one of the DefinitionsForOo. Well, I've provided a list of paradigms and a language I believe serve as counter-examples. Either demonstrate that these fit the DefinitionsForOo, or admit your argument here was ludicrous.}
You are using argument-via-mass-BookStop on obscure languages; you are not presenting an alternative definition. I'm not going to play that game.
{Are you saying "everything" doesn't include what you consider to be "obscure languages"? That seems quite illogical to me. "Everything" either must be complete with regards to the domain, or it's a lie. It isn't even a UsefulLie, in this case.}
SeptemberZeroNine
Linus Torvalds On Visual Basic