The unconditional checkfile exception condition idiom
-
@Mason Wheeler said:
Only if you really stretch things, as this author did.He even quoted the LSP up at the top: Subtypes must be substitutable for their base types. And then he goes and gives an answer that has nothing to do with base types and subtypes, and calls it Liskov Substitution? And then to justify it, he makes the completely unfounded assertion that it's not really about inheritance, it's about "behavior." Caroll's Humpty Dumpty comes to mind...
I'm sorry, we can't help those who refuse to be helped. Did a prototypal language run over your dog?
-
@boomzilla said:
@Mason Wheeler said:
Only if you really stretch things, as this author did.He even quoted the LSP up at the top: Subtypes must be substitutable for their base types. And then he goes and gives an answer that has nothing to do with base types and subtypes, and calls it Liskov Substitution? And then to justify it, he makes the completely unfounded assertion that it's not really about inheritance, it's about "behavior." Caroll's Humpty Dumpty comes to mind...
I'm sorry, we can't help those who refuse to be helped. Did a prototypal language run over your dog?
Ultimately, I'd say this has nothing to do with Liskov (not even Mason Wheeler's incorrect interpretation of it). Instead I see it devolving into a static-vs.-dynamic typing argument, which I have no interest in.
-
@Mason Wheeler said:
And then to justify it, he makes the completely unfounded assertion that it's not really about inheritance, it's about "behavior."
Behavior of subtypes is precisely what LSP is all about.
-
@morbiuswilters said:
Ultimately, I'd say this has nothing to do with Liskov (not even Mason Wheeler's incorrect interpretation of it). Instead I see it devolving into a static-vs.-dynamic typing argument, which I have no interest in.
If I thought this thread were still in good faith, I might agree with you. I think it's become a personalized defensive rearguard action of ignorance. But I'm willing to concede that Javascript doesn't match Mason's concept of OO.
-
@morbiuswilters said:
@Mason Wheeler said:
@morbiuswilters said:
@Mason Wheeler said:
What can you do with the prototype model that you can't trivially emulate in C?
What the fuck does that have to do with anything?
Because I'm talking about what differentiates OOP from procedural programming. If you can trivially accomplish everything that an OO language brings to the table in a non-OO language, then you don't have a different paradigm, you just have procedural programming with funny syntax. As I said several posts ago.
That's a silly conclusion to draw. First off, I take issue with your use of "trivial"; I would hardly consider most aspects of OOP (prototype or class) to be trivial to implement in C. And since any OOP language can be represented in C (after all, most of the runtimes are written in C) it seems like a meaningless metric. Regardless, C++ was implemented for a while in the C preprocessor and I doubt most people would consider it a non-OOP language.
Now you're talking about Turing-equivalence, which is not what I meant. That "preprocessor" was an entire compiler unto itself. This is not a trivial transformation we're talking about; it's turning code from one language into functionally equivalent code in another, different Turing-complete language that just happened to share a lot of similar syntax. He could just as easily have implemented it as a "preprocessor" that outputs Pascal or Fortran. If you don't understand the difference between Turing-equivalence and varying levels of expressive power in higher-level languages, why are you even taking part in this discussion?
And if you don't consider most aspects of OOP trivial to implement in C, can you give examples? What OO feature, aside from inheritance, is difficult to represent in C? (Note that I said OO feature--as in actually related to programming with objects--and not "feature found in an OO language." C++'s templates would be an example of the latter.)
-
@morbiuswilters said:
@Mason Wheeler said:
And then to justify it, he makes the completely unfounded assertion that it's not really about inheritance, it's about "behavior."
Behavior of subtypes is precisely what LSP is all about.
Yes, behavior of subtypes. Which are distinctly lacking from the article in question.
-
@Mason Wheeler said:
If you don't understand the difference between Turing-equivalence and varying levels of expressive power in higher-level languages, why are you even taking part in this discussion?
... sez the person who thinks JavaScript isn't OO.
-
@Mason Wheeler said:
Yes, behavior of subtypes. Which are distinctly lacking from the article in question.
I guess you didn't get down to where the FastVehicle subtype of Vehicle came up, huh?
-
@blakeyrat said:
@Mason Wheeler said:
If you don't understand the difference between Turing-equivalence and varying levels of expressive power in higher-level languages, why are you even taking part in this discussion?
... sez the person who thinks JavaScript isn't OO.
Yes, I do say that, and I've actually provided a reasoned argument to support my position. What I see from the people claiming it is is mostly appeal to authority (so-and-so says it is, therefore it must be true) and, in this case, begging the question.
-
Ok, but:
1) You're wrong.
2) I'm confident you've never actually used, or even read-up on, JavaScript.
-
@blakeyrat said:
I'm confident you've never actually used, or even read-up on, JavaScript.
I'm sure you are. That doesn't make it true. I wouldn't be talking about JavaScript if I had never used it. Not by choice, mind you, but I've done a fair amount of work in it, enough to know how the language works.
-
@Mason Wheeler said:
Now you're talking about Turing-equivalence, which is not what I meant.
Nope. My point was that you are making a silly argument that declares everything but class-based inheritance to be trivial in C and also that the difficulty of representation in C is somehow the measure of object-orientation.
@Mason Wheeler said:
And if you don't consider most aspects of OOP trivial to implement in C, can you give examples? What OO feature, aside from inheritance, is difficult to represent in C?
You're the one that is throwing around claims about how trivial something is or is not in C; I think that's a senseless metric, as would every other definition of OO that I've ever seen. Also, once again, Javascript has inheritance, just not class-based. As for difficulty, wouldn't prototype-based inheritance be non-trivial to do in C? What about subtype polymorphism? I wouldn't classify either as non-trivial.
-
@morbiuswilters said:
As for difficulty, wouldn't prototype-based inheritance be non-trivial to do in C?
Not if you understand how it's done. In JavaScript, all objects are (conceptually at least, if not necessarily actually implemented as) an associative array of name/value pairs. Associative arrays can be implemented easily enough in C as a hash table. (Creating a data type to represent an abstract "any value" of a dynamic type system is tricker, but that's not the point under discussion here.) Once you have a name-value hash table, you just set up your prototype-emulation code to make sure that every object has a Prototype entry in its table. That doesn't require language-level support to get right, the way Liskov substitution does.
-
@Mason Wheeler said:
Yes, I do say that, and I've actually provided a reasoned argument to support my position. What I see from the people claiming it is is mostly appeal to authority (so-and-so says it is, therefore it must be true) and, in this case, begging the question.
You can reason all day long, but when you start from bad assumptions, you're still wrong. I found an example of javascript doing exactly what you claimed was the essence of OOP, and you still deny the obvious. If you can't even agree with yourself...
-
@Mason Wheeler said:
Not if you understand how it's done. In JavaScript, all objects are (conceptually at least, if not necessarily actually implemented as) an associative array of name/value pairs. Associative arrays can be implemented easily enough in C as a hash table. Once you have a name-value hash table, you just set up your prototype-emulation code to make sure that every object has a Prototype entry in its table.
How would class-based inheritance be significantly more difficult to add on there?
@Mason Wheeler said:
(Creating a data type to represent an abstract "any value" of a dynamic type system is tricker, but that's not the point under discussion here.)
Of course it is. You maintain that all features of Javascript are trivial to implement in C. That means every feature must be easy to implement. (Of course, I think "trivial to implement in C" is a retarded metric that shows little understanding of the fundamentals of OOP.)
@Mason Wheeler said:
That doesn't require language-level support to get right, the way Liskov substitution does.
Why do you keep saying this? I've already told you that Liskov substitution is not a language-level feature, it's a design principle. LSP is the principle of guaranteeing behavioral consistency when using subtype polymorphism. Subtype polymorphism is a language feature, but Javascript does support it.
-
@morbiuswilters said:
@Mason Wheeler said:
That doesn't require language-level support to get right, the way Liskov substitution does.
Why do you keep saying this?
Mason Wheeler has severe "I can't admit I was wrong" disease. Tragic.
Mason, just say, "ok I was wrong." It's not hard. It won't hurt you. You don't have to be right all the time. We're ok with it.
