A reference about OOP?

For academic reasons I'm interested in finding a reference on OOP to cite. Specifically, I'm interested in the logical change from functional to object-oriented programming because I believe it provides a nice metaphor/parallel for a project I'm working on, with a similar change in perspective.

It should be something academically acceptable to cite (that is, not Wikipedia, and best if it's not a random webpage), so that's why it's a little hard to figure out what to cite on this.

If you know of a clear reference on the conceptual difference with OOP out there, that would be helpful.


(To be clear, I understand the difference, but I'm looking for an authority to cite on it, perhaps with a clear quotation on what the conceptual difference is.)

You might like this. Fairly authoritative, I'd say.

What exactly are you looking for? Not tutorials or anything language-specific, I assume. But concepts related to...? how it approaches certain tasks? the "thought" process behind it? strengths/weaknesses vs. functional programming?

Have you looked through the references on wikipedia?

I can find some references (many actually), but I'm just wondering if anyone knows of a "best" resource out there on this. The one you linked to is interesting. It's also a personal website, rather than a book, so I can cite that but in theory it would be better to have a published source. (And I can find plenty of those, but it's unclear which ones are best.)

I'll explain how I'm planning to use this. My project has nothing to do with programming. It's about linguistics, specifically semantics (and syntax), or meaning (and grammatical structure). I'm trying to imagine a new theory (or perhaps find an existing one that lines up with what I'm thinking).

Part of what I think is important is to include structure within the meanings. That is, rather than a "flat" meaning as output, it should be some sort of construct that has separable parts that can be considered independently. As an example, we can think of a meaning like "I see a computer" as a flat meaning-- just a whole meaning that lines up with those words. Or we can think of it as something within internal structure where that whole meaning is still there but we can also refer to parts like "a computer". This is useful for things like pronouns-- "I see a computer. It is nice." 'It' refers back to the computer, but not to the full sentence.

Semantic theories usually focus on the "flat" meanings, called "truth-conditional semantics", just based on what it would mean for the sentence to be true-- but not about the individual parts within that full meaning. These theories look very much like functional programming. In fact, they include functions and arguments. For example, "John is sleeping" would look something like SLEEP(john). And in many ways, that works. But it doesn't give the internal separable meanings I'd like.

As I see it, one solution here is to (literally) add objects to the representation. This is parallel to OOP. Instead of just applying functions and getting outputs, we can think about individual things that are manipulated by functions. So we can rewrite "John is sleeping" as something like JOHN->sleep(). Now we can talk about two things: i) "John is sleeping"; ii) John (because he's an object, not lost somewhere inside the SLEEP() function).

Technically, the functional vs OOP approaches to programming are a metaphor for what I'm doing. At the time time, it's almost literally applying the ideas to some extent.

In short:
I'll use a traditional "x is to y as a is to b" analogy here.
My theory is to standard semantic theories as OOP is to functional programming.
It adds an extra layer to how the system works, but it also conceptually is about objects rather than about functions/meanings/results.



I'm hoping to get three things out of OOP approaches to programming:
1. A way for me to think about the problem. This is done, or at least it's started-- I'm still working on the theory obviously.
2. A citation for the conceptual difference that I will be applying here (at least as a metaphor).
3. A citation for the history of OOP to compare to the history of linguistics. See below--


Linguistics actually has been significantly influenced by programming (as well as by math and logic). But from what I can tell it's only influenced by functional programming, which is what existed when the main theories started in the 50s-60s. OOP wasn't around then and after that point, linguists worked internally with a base of what was already being used. So linguistics has not been influenced by OOP because it wasn't around early and the theories haven't looked externally for influenced from OOP since then. Basically the programming models that influenced early linguistics are now outdated and significantly improved, while linguistics is still based on the older stuff-- time for an upgrade, I say. But it also explains it historically-- that's why we don't have these kinds of models in linguistics, because they weren't around.


The theory is barely at a point where I can express it outside of my head, but it's getting there. I'm working this semester to try to make it more concrete.

Quote:

---

Originally Posted by djr33

Semantic theories usually focus on the "flat" meanings, called "truth-conditional semantics", just based on what it would mean for the sentence to be true-- but not about the individual parts within that full meaning. These theories look very much like functional programming. In fact, they include functions and arguments. For example, "John is sleeping" would look something like SLEEP(john). And in many ways, that works. But it doesn't give the internal separable meanings I'd like.

As I see it, one solution here is to (literally) add objects to the representation. This is parallel to OOP. Instead of just applying functions and getting outputs, we can think about individual things that are manipulated by functions. So we can rewrite "John is sleeping" as something like JOHN->sleep(). Now we can talk about two things: i) "John is sleeping"; ii) John (because he's an object, not lost somewhere inside the SLEEP() function).

Technically, the functional vs OOP approaches to programming are a metaphor for what I'm doing. At the time time, it's almost literally applying the ideas to some extent.

---

Very literal. Any programmer would see it right away. I think the two fields are very tightly coupled, but no one exactly realizes it yet. Odd, since so many programmers are so anal (forgive the expression) and nit-picky about how people speak/write, while, conversely, I think many linguists would "slip right in" to programming if they ever tried.

Your JOHN->sleep() example could also be taken as sleep()->JOHN (not sleep->JOHN(), if you follow what I'm hinting at), JOHN->setState->sleep(), or sleep->assignState->JOHN.

...I'd use prototypical (as opposed to classical) inheritance in my theory, I think. These word-objects would be better suited to javascript than php.

When you get down to it, you're talking about assigning and interacting with context. Every word is an object. The sentence as a whole would also be an object, containing the word objects and mapping their relationships (this could be a tie-in to the existing, "functional" theories you mention, since the sentence object could be evaluated as a boolean against any other sentence or condition (making it "truth-conditional")).

You're actually expressing it pretty well. I think I'd be interested in reading this when you're done, if you were amenable.

The example I gave was intentionally literal. It's a convenient one, because it's reversible without any real consequences. The trickier cases are when it's a transitive verb. In those cases, the usual approach is to use SEE(x,y), rather than something like x->SEE() and y->SEEN(). In fact, it's hard for me to imagine how to do it that way. So perhaps it would be best to use something like SEE()->x; SEE()->y;, but that ends up confusing as well.

The other aspect is that I don't mean it would only have verbs or nouns as objects. All parts of the sentence could be objects, including the sentence itself. I haven't worked out any of this yet in detail though.

You're also right that it wouldn't be incompatible with a truth-conditional kind of semantics; it would just be more on top of it (but potentially shift how that would be conceptualized in some ways).

And I'll be happy to share it as it progresses-- not sure it'll ever/soon be "done" :)

have you ever read about __call()? It's a PHP 5 way of handling calls to inaccessible (i.e., nonpublic and/or nonexistent) methods. Other OO languages have similar things - Ruby's method_missing, for example.

instead of SEE( JOHN,light ), you could use JOHN->see( light ). The method see() doesn't really exist in JOHN, but it would map to a method that "looks up" the SEE object and applies SEE( JOHN,light ) for you. The JOHN object might even be extended with its own SEE method, which could do some operation on the parameters and/or results for the "real" SEE object (for example, if JOHN is color-blind).

Interesting.

Semantics is based on "lambda calculus", which is a formal logic system based on functions and arguments. It's possible in that, with a little higher order logic, to rearrange argument so that f(x,y) is equivalent to g(y,x) if you need it. Or even f(x) is equivalent to x(f), if you work hard enough.

It's more or less arbitrary which one is the function and which one is the argument.

The tough part is working out how it is all compositional so that it adds up to the right meaning.

So there can be a lot of symbol manipulation in the input stages (such as something like __call()), but it will end up being logically equivalent to applying it in the other direction, I think.

In the end I'm not actually building a computer that can talk, but if I were, computational tricks like __call() would be useful. Certainly as a concept it applies well to what would be a possible strategy here.

I was thinking lambda functions would be useful (perhaps necessary). That is, if we were actually talking about programming. I guess that was good speculation.

Also that a new form of inheritance might be needed. Something like "broad" or "contextual" prototypical inheritance.

I realize there are a couple terms you're using that I think I understand generally but not exactly as technical terms as you're applying them here-- mostly "prototypical inheritance". Any quick links to point me in the right direction on that?


By the way, the more I think about it, the full approach will be a combination of everything discussed above. A sentence like "John saw Bill" will end up working out something like this:

PHP Code:

---

$x = new Entity;
$x->John();
$y = new Entity;
$y->Bill();
$z = new Entity;
$z->See($x,$y);
$z->tense('Present');
//... 


---

There's obviously something a little weird about the functions "John()" and so forth that might not be defined. But that could be worked out technically in a few ways. One option would be to simply have a default ->set('property') method.
Part of the complication also comes from trying to actually represent this in PHP, which isn't really my goal. (It could be represented in PHP, but might require slightly different notations. Instead, it would be simpler as this pseudo-code:

Code:

---

x->John;
y->Bill;
z->See(x,y);
z->Tense('Present');
...

---

It's also compatible with the old format but simply keeping the variables/objects for reference:

Code:

---

John(x); //or set(x,'John');
Bill(y);
See(z,x,y);
Tense(z,'Present');

---

...very rough, but good enough. I'd still prefer the conceptual perspective of OOP, but the effects would be roughly equivalent I think.

you know how objects are defined by classes in PHP? You write a class definition, and optionally use extend to set a base class. Even if you don't, you extend the stdClass by default. You can extend that class with another, and so on if you like. That's "classical" inheritance.

javascript uses "prototypical" inheritance. There's no "definition," instead you start by creating an instance of an existing object (either an object literal {}, or using new to make a new instance of one you made elsewhere). Then, you add your own properties and methods as you see fit.

A big difference is that prototypical objects are mutable: where in PHP you define a class and "that's it," in javascript you can create an object, add a method, create a new object that inherits from the one you just made, and then go back and change what that function does - and both objects reflect the changes. If you give the newer object a method with the same name, though it will use that one instead (and the first object won't have access to it).

There's much more in the way of practical differences and nuances, though. Douglas Crockford explains it much better then I can. I think this video is the one I'm thinking of, too, but I don't have time right now to watch through it and make sure. It's a good one, anyway.