6 ms·

The Wikipedia page to which you keep referring does not support the argument that mutability is "core property" of OOP. The quote you've cited (far above at thi

The Wikipedia page to which you keep referring does not support the argument that mutability is "core property" of OOP. The quote you've cited (far above at this point) is referring to a feature of objects, not OOP. OOP encompasses range of features. You can explore them on that very same page under the "Features" section. You will certainly notice that "Mutability" is not listed as a feature. OOP is an _approach_. Simply using objects does not mean you are practicing OOP any more than using functions means you are practicing FP. I urge to to a ctrl+F on "mutable" and read the top 2 (of 3) passages where it is referenced (the third is not relevant): > ... in most OOP languages, in particular in all those that allow mutable objects. > ... in OOP languages (with mutable objects) ... The clarifications in the above passages are unnecessary if mutability is considered a necessary feature for OOP. If that's not enough, how about you read the first sentence of https://en.wikipedia.org/wiki/Immutable_object https://en.wikipedia.org/wiki/Immutable_object: > In object-oriented and functional programming, an immutable object (unchangeable[1] object) is an object whose state cannot be modified after it is created. If immutable objects are incompatible with OOP, why is it included in the above? Are you suggesting that if I write a Java program and I use all of the features of OOP (inheritance, polymorphism, encapsulation, etc.) but don't use mutability, that my system is better understood as functional? Come on. What about an OOP system that doesn't mutate by design? Not every program requires changes of state. We need to put this to rest. I can pretend "this never happened". After all, this entire argument is not relevant to the point I was trying to make (the whole goalpost thing). > Much easier to change a function operating on the wrong type than it is to change a method intrinsically tied to scoped variables _This_ is to the point I was trying to make. The above is simply untrue. If I have a function referenced all over my code base, `validate(giraffe)`, and we change the signature to `validate(gorilla)`, it isn't any easier to refactor the system than if it were modeled in OOP. In both cases, the _caller_ needs to have a reference to a different piece of data in order to call our `validate` function. Which means the caller of the caller needs to have a different piece of data (so now the caller needs to change), etc. up the stack. In the end, the most flexible solution in either paradigm is to "inject" the appropriate data (`giraffe`/`gorilla`) via the "DI" mechanism that the paradigm supports. In OOP this is in the constructor. In FP we can use partial application. These two concepts _are_ isomorphic. I am _not_ saying that OOP is "the same as" all other forms. I am saying, in terms of the pitfalls regarding modelling a domain, all forms are the same. As I understand it, this is the argument your OP was making (you just left FP out of it). I agree that OOP is worse than FP. There are a few features of FP that make it superior in many respects (notably required immutability and an algebraic type system).

crimsonalucard 7y ago
>The Wikipedia page to which you keep referring does not support the argument that mutability is "core property" of OOP. The quote you've cited (far above at this point) is referring to a feature of objects, not OOP. OOP encompasses range of features. You can explore them on that very same page under the "Features" section. You will certainly notice that "Mutability" is not listed as a feature. OOP is an _approach_. Simply using objects does not mean you are practicing OOP any more than using functions means you are practicing FP. Dude. OOP is programming oriented around objects. The core feature of OOP is objects. Any feature that an object possesses is a "core property." Also it's a pretty safe bet that anything mentioned in the first paragraph of the Definition of OOP is likely a core property. >If immutable objects are incompatible with OOP, why is it included in the above? >Are you suggesting that if I write a Java program and I use all of the features of OOP (inheritance, polymorphism, encapsulation, etc.) but don't use mutability, that my system is better understood as functional? Yes I am. 100% if you use immutability your program is isomorphic to functional programming. It's included because you CAN do this. Just like how you can do functional programming in a procedural language. If you want to compare OOP to other styles you compare the features that are variant not the features that are identical. >_This_ is to the point I was trying to make. The above is simply untrue. If I have a function referenced all over my code base, `validate(giraffe)`, and we change the signature to `validate(gorilla)`, it isn't any easier to refactor the system than if it were modeled in OOP. it is easier. We've talked about the deeper difference. validate in OOP is attached to a concrete instance, it cannot be moved up to a more abstract type without affecting everything it's attached to. >What about an OOP system that doesn't mutate by design? You may lack the insight to realize it, but if you are doing this your program is basically a functional one. Your loops become recursion, you become unable to write procedural steps and your methods become isomorphic to stateless functions. You are no longer in OOP land. >I agree that OOP is worse than FP. There are a few features of FP that make it superior in many respects (notably required immutability and an algebraic type system). An algebraic type system is not exclusive to FP. It's included in Rust which is not an FP language. It has nothing to do with OOP or FP.
- kingdomcome50 7y ago
  >OOP is programming oriented around objects. The core feature of OOP is objects Objects DO NOT HAVE to be mutable. As I have _repeatedly_ stated, you are building a straw-man. That is, you are creating your _own_ definition of OOP (objects and to some degree FP) and using it to support your argument about modularity. Refer to the "Specialized Objects" section of: https://en.wikipedia.org/wiki/Object_(computer_science) https://en.wikipedia.org/wiki/Object_(computer_science) >Immutable object: an object set up with a fixed state at creation time and which does not change afterward. Crystal clear. Even the single sentence in which you are basing this entire waste-of-time argument on: >A feature of objects is an object's procedures that can access and often modify the data fields of the object with which they are associated in no way supports your conclusion with any rational reading. A "feature" of objects is procedures that can "often" modify fields. It takes some serious gymnastics to read that as "mutability is a required property of OOP". I have yet to find a resource that supports your definition of OOP (and I'm looking!). >if you use immutability your program is isomorphic to functional programming Being isomorphic to a functional program doesn't mean the program isn't OOP. From the same page above: >Object-oriented programming is an approach to designing modular reusable software systems OOP is an approach. It is the _approach_ one takes when designing a system that determines whether or not that system should be understood as OOP. If the approach uses the "Features" of OOP (listed on the wiki), then the system is OOP. Your entrenchment on this topic is astounding. Again, I don't have to be wrong about `noun.verb` vs `verb(noun)` for your conclusions about how we abstract software to stand. My intention wasn't to disagree with you, it was simply to point out that all paradigms suffer from modularity problems as they relate to functions acting on state. >it is easier. We've talked about the deeper difference No, but we have. And I've clearly demonstrated that same problem presents itself. That's how we got here. You needed to change the constraints of the problem (that objects _must_ mutate) in order to make a coherent argument (the straw-man). That got us to this separate argument about the definition of OOP (moved goal posts). Here is the moment above when you played your hand (and lost the argument): >A stateless function versus a function that carries it's own mute-able state. There is MORE than a semantic difference. The semantic difference you're referring to is when the SELF value is immuteable. In that case the two ways of calling the function become more similar, but THAT is NOT OOP Instead of doubling down and starting this dumper-fire of a discussion, you could have simply responded with something like: "That's correct. Which makes it even more pragmatic that we strive to abstract the server model into code, because the problems with modularity/distribution cannot be avoided in _any_ programming paradigm. That is, the level of abstraction where we WRITE code is not the same, or appropriate level of abstraction used to modularize/distribute code. If, instead of explicitly hard-coding the boundaries of communication into a system, we could abstract the boundaries into compilation as a matter of configuration, it would allow for any arbitrary level of modularization/distrubution without the need to change the source code itself". The above makes a great point (your point), and has actually served as inspiration for my latest side-project. So kudos to you for that.

crimsonalucard 7y ago

>The Wikipedia page to which you keep referring does not support the argument that mutability is "core property" of OOP. The quote you've cited (far above at this point) is referring to a feature of objects, not OOP. OOP encompasses range of features. You can explore them on that very same page under the "Features" section. You will certainly notice that "Mutability" is not listed as a feature. OOP is an _approach_. Simply using objects does not mean you are practicing OOP any more than using functions means you are practicing FP. Dude. OOP is programming oriented around objects. The core feature of OOP is objects. Any feature that an object possesses is a "core property." Also it's a pretty safe bet that anything mentioned in the first paragraph of the Definition of OOP is likely a core property. >If immutable objects are incompatible with OOP, why is it included in the above? >Are you suggesting that if I write a Java program and I use all of the features of OOP (inheritance, polymorphism, encapsulation, etc.) but don't use mutability, that my system is better understood as functional? Yes I am. 100% if you use immutability your program is isomorphic to functional programming. It's included because you CAN do this. Just like how you can do functional programming in a procedural language. If you want to compare OOP to other styles you compare the features that are variant not the features that are identical. >_This_ is to the point I was trying to make. The above is simply untrue. If I have a function referenced all over my code base, `validate(giraffe)`, and we change the signature to `validate(gorilla)`, it isn't any easier to refactor the system than if it were modeled in OOP. it is easier. We've talked about the deeper difference. validate in OOP is attached to a concrete instance, it cannot be moved up to a more abstract type without affecting everything it's attached to. >What about an OOP system that doesn't mutate by design? You may lack the insight to realize it, but if you are doing this your program is basically a functional one. Your loops become recursion, you become unable to write procedural steps and your methods become isomorphic to stateless functions. You are no longer in OOP land. >I agree that OOP is worse than FP. There are a few features of FP that make it superior in many respects (notably required immutability and an algebraic type system). An algebraic type system is not exclusive to FP. It's included in Rust which is not an FP language. It has nothing to do with OOP or FP.

kingdomcome50 7y ago
>OOP is programming oriented around objects. The core feature of OOP is objects Objects DO NOT HAVE to be mutable. As I have _repeatedly_ stated, you are building a straw-man. That is, you are creating your _own_ definition of OOP (objects and to some degree FP) and using it to support your argument about modularity. Refer to the "Specialized Objects" section of: https://en.wikipedia.org/wiki/Object_(computer_science) https://en.wikipedia.org/wiki/Object_(computer_science) >Immutable object: an object set up with a fixed state at creation time and which does not change afterward. Crystal clear. Even the single sentence in which you are basing this entire waste-of-time argument on: >A feature of objects is an object's procedures that can access and often modify the data fields of the object with which they are associated in no way supports your conclusion with any rational reading. A "feature" of objects is procedures that can "often" modify fields. It takes some serious gymnastics to read that as "mutability is a required property of OOP". I have yet to find a resource that supports your definition of OOP (and I'm looking!). >if you use immutability your program is isomorphic to functional programming Being isomorphic to a functional program doesn't mean the program isn't OOP. From the same page above: >Object-oriented programming is an approach to designing modular reusable software systems OOP is an approach. It is the _approach_ one takes when designing a system that determines whether or not that system should be understood as OOP. If the approach uses the "Features" of OOP (listed on the wiki), then the system is OOP. Your entrenchment on this topic is astounding. Again, I don't have to be wrong about `noun.verb` vs `verb(noun)` for your conclusions about how we abstract software to stand. My intention wasn't to disagree with you, it was simply to point out that all paradigms suffer from modularity problems as they relate to functions acting on state. >it is easier. We've talked about the deeper difference No, but we have. And I've clearly demonstrated that same problem presents itself. That's how we got here. You needed to change the constraints of the problem (that objects _must_ mutate) in order to make a coherent argument (the straw-man). That got us to this separate argument about the definition of OOP (moved goal posts). Here is the moment above when you played your hand (and lost the argument): >A stateless function versus a function that carries it's own mute-able state. There is MORE than a semantic difference. The semantic difference you're referring to is when the SELF value is immuteable. In that case the two ways of calling the function become more similar, but THAT is NOT OOP Instead of doubling down and starting this dumper-fire of a discussion, you could have simply responded with something like: "That's correct. Which makes it even more pragmatic that we strive to abstract the server model into code, because the problems with modularity/distribution cannot be avoided in _any_ programming paradigm. That is, the level of abstraction where we WRITE code is not the same, or appropriate level of abstraction used to modularize/distribute code. If, instead of explicitly hard-coding the boundaries of communication into a system, we could abstract the boundaries into compilation as a matter of configuration, it would allow for any arbitrary level of modularization/distrubution without the need to change the source code itself". The above makes a great point (your point), and has actually served as inspiration for my latest side-project. So kudos to you for that.