As described in issue3, all that one sees in OO languages today boils down to a tuple containing an opaque state and a > dispatch table. OO languages provides different ways of constructing this tuple, but they all come down to the same thing.
Sigh.
No..
Objects are a means to preserving correctness by encapsulating state in methods that protect the class invariant.
ie. A correctly design class can never move into an invalid state as it provides no method to do so.
A correctly design OO program can never move into an invalid state as it is composed of correctly design classes.
Alas, most OO language provide too little support for this, and way to few OO programmers understand this.
I don’t think we can meaningfully talk about what a “correctly designed OO program” should look like or what it means. People called Java OO, they call Python OO, and they call Smalltalk OO. All of these have significantly different views on what OO means. Python does very little to protect class invariants. So who is anyone to say whether that is correct OO or not?
However, what all of these implementations have in common is what an object is, and that is a tuple containing an opaque state and a dispatch table.
“A correctly design OO program can never move into an invalid state as it is composed of correctly design classes”
That is one a per-program basis. You conceivably get that effect using object oriented-C. Creating a program which satisfies this condition is the job of the designer/programmer. An object-orient language just provides support facilities to allow this to happen. (I also like asserts/design-by-contract, which makes behavior which might put an object into a dubious state just fail hard and instantly).
Object orientation has certainly suffered from terrible hype and from evangelists who gave the impression just using OO would guarantee correct design, encapsulation, code-reuse and free breakfasts at Dennys. The real story is a useful tool, an approach with discreet, limited advantages if you go about it correctly. Of course, anything else that achieves the same success as OO will have the mind-numbing hype attached to it. And then those who appreciate OO’s discreet uses will be able to laugh.
@tedu took the words out of my mouth, I don’t see what not moving into an invalid state has to do with OO. What does have to do with OO is the primtiives it gives you to accomplish this, which is a tuple with an opaque state and a dispatch table.
I’m not sure what the opposite of OO is (verb oriented programming?) but a correctly designed verb/lambda/whatever can never move into an invalid state either. Even more generally, a correctly designed anything is correct.
I’m not sure what the point of the article is. Sure objects can leak, obfuscate, meddle, overreach and break. So can many other constructs. I’d argue that C++ or Java are still better than C because they give you options, you can pick any number of the more complex features or write something resembling procedural or functional programming (I know, it isn’t quite the same as a real functional language, but you get the idea). The article didn’t really elaborate on what the preferred construct is, or are we just using OO incorrectly?
Formally:
Premise A. Supporting evidence B for Premise A. Premise C.
What am I missing? Are these actually two ‘articles’?
Sigh.
No..
Objects are a means to preserving correctness by encapsulating state in methods that protect the class invariant.
ie. A correctly design class can never move into an invalid state as it provides no method to do so.
A correctly design OO program can never move into an invalid state as it is composed of correctly design classes.
Alas, most OO language provide too little support for this, and way to few OO programmers understand this.
I don’t think we can meaningfully talk about what a “correctly designed OO program” should look like or what it means. People called Java OO, they call Python OO, and they call Smalltalk OO. All of these have significantly different views on what OO means. Python does very little to protect class invariants. So who is anyone to say whether that is correct OO or not?
However, what all of these implementations have in common is what an object is, and that is a tuple containing an opaque state and a dispatch table.
And even more confusing for most everyone: People call CLOS OO.
I think John Carter’s observation is cogent.
“A correctly design OO program can never move into an invalid state as it is composed of correctly design classes”
That is one a per-program basis. You conceivably get that effect using object oriented-C. Creating a program which satisfies this condition is the job of the designer/programmer. An object-orient language just provides support facilities to allow this to happen. (I also like asserts/design-by-contract, which makes behavior which might put an object into a dubious state just fail hard and instantly).
Object orientation has certainly suffered from terrible hype and from evangelists who gave the impression just using OO would guarantee correct design, encapsulation, code-reuse and free breakfasts at Dennys. The real story is a useful tool, an approach with discreet, limited advantages if you go about it correctly. Of course, anything else that achieves the same success as OO will have the mind-numbing hype attached to it. And then those who appreciate OO’s discreet uses will be able to laugh.
@tedu took the words out of my mouth, I don’t see what not moving into an invalid state has to do with OO. What does have to do with OO is the primtiives it gives you to accomplish this, which is a tuple with an opaque state and a dispatch table.
I’m not sure what the opposite of OO is (verb oriented programming?) but a correctly designed verb/lambda/whatever can never move into an invalid state either. Even more generally, a correctly designed anything is correct.
Yes, it’s two articles, like a magazine.
The page seems to be “Snowsuit Zine” #10, consisting of, indeed, two articles.
I’m not sure what the point of the article is. Sure objects can leak, obfuscate, meddle, overreach and break. So can many other constructs. I’d argue that C++ or Java are still better than C because they give you options, you can pick any number of the more complex features or write something resembling procedural or functional programming (I know, it isn’t quite the same as a real functional language, but you get the idea). The article didn’t really elaborate on what the preferred construct is, or are we just using OO incorrectly?
Lobstered to death.
What do you mean?
oo deniers