3 ms·

> But to deny that the change in philosophy doesn't exist because it's "possible" to do OOP in rust is basically denying the existence of something that CLEARLY

> But to deny that the change in philosophy doesn't exist because it's "possible" to do OOP in rust is basically denying the existence of something that CLEARLY exists. Apologies for not understanding this - if the delineation between OOP and not OOP is so clear, it should be easy to come up with an objective criterion for being OOP that C++ satisfies and Rust doesn't satisfy. I'm not sure what that would be. Inheritance? If that can't be done, then I'd say it's a matter of opinion.

deltasevennine 4y ago
Inheritance is not oop. If you think about it inheritance is syntactic sugar around definitions of objects. Not really a programming style because it doesn't change the structure of your program in terms of state and logic. These are simply definitions, no control flow is defined here. I have object a and I have object b. A is similar to b. How do I define a in terms of b? That is inheritance. Functional languages can support this type of syntactic sugar. It is not exclusive to OOP.
deltasevennine 4y ago
It can be done. But you don't compare it to rust. You compare it to programming paradigms. This is because rust can be bent to support oop along with almost every language out there. So what you imagine is this: A venn diagram. The left is all other programming paradigms. The right is oop. Most of the oop stuff is in the intersection of these circles. What's to the right is encapsulated mutation. Getters and setters and variants of these two concepts. Mostly setters though. All of oop is simply instantiated objects manipulating and communicating with each other with getters and setters. This is unique to oop. You can't even imitate this with a functional language. But it shouldn't be functional vs. oop. You can avoid writing any getters and setters in your program and while you wouldn't be doing oop, you wouldn't be doing functional either. mutate_function(a) is isomorphic to a.mutate_method(). The latter is oop the former is not. There is a design tradeoff here that's actually well known and named. I forgot what it was called though. But also note how I used mutate here in the names. It's because this property of mutation is the main differentiator that causes oop to be different. If everything was immutable but you still used methods everywhere it wouldn't be uniquely oop. It would be functional as well. And if you think about it is the very property of mutation that allows objects to communicate and mutate one another which fits with our intuition of what oop is. That's why methods that mutate should formally define oop and what it actually is.

deltasevennine 4y ago

Inheritance is not oop. If you think about it inheritance is syntactic sugar around definitions of objects. Not really a programming style because it doesn't change the structure of your program in terms of state and logic. These are simply definitions, no control flow is defined here. I have object a and I have object b. A is similar to b. How do I define a in terms of b? That is inheritance. Functional languages can support this type of syntactic sugar. It is not exclusive to OOP.

deltasevennine 4y ago

It can be done. But you don't compare it to rust. You compare it to programming paradigms. This is because rust can be bent to support oop along with almost every language out there. So what you imagine is this: A venn diagram. The left is all other programming paradigms. The right is oop. Most of the oop stuff is in the intersection of these circles. What's to the right is encapsulated mutation. Getters and setters and variants of these two concepts. Mostly setters though. All of oop is simply instantiated objects manipulating and communicating with each other with getters and setters. This is unique to oop. You can't even imitate this with a functional language. But it shouldn't be functional vs. oop. You can avoid writing any getters and setters in your program and while you wouldn't be doing oop, you wouldn't be doing functional either. mutate_function(a) is isomorphic to a.mutate_method(). The latter is oop the former is not. There is a design tradeoff here that's actually well known and named. I forgot what it was called though. But also note how I used mutate here in the names. It's because this property of mutation is the main differentiator that causes oop to be different. If everything was immutable but you still used methods everywhere it wouldn't be uniquely oop. It would be functional as well. And if you think about it is the very property of mutation that allows objects to communicate and mutate one another which fits with our intuition of what oop is. That's why methods that mutate should formally define oop and what it actually is.