5 ms·

> by default are not virtual and cannot be overridden by a successor class. Non virtual methods has nothing to do with OOP, they are a mere sugar for function

> by default are not virtual and cannot be overridden by a successor class. Non virtual methods has nothing to do with OOP, they are a mere sugar for function calling. We are talking about OOP, which is defined by late binding/open recursion, i.e. virtual methods, and the perils of open recursion. > You cannot accidentally create an opportunity for breaking factorial by defining 'pred', you'd need to explicitly declare 'pred' as virtual. If you don't do it, factorial cannot be broken and there is no problem. Ok, it seems you are confused by the trivial nature of the example, here is a real world example: https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/merge_requests/95/commits https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/mer... A decoder implementation calls GstElement's `change_state` method, which calls (through the long chain of calls) child's decide_allocation which calls parent and so on and so forth and in the end you have a deadlock. This is pure OOP, where each Class provides needed virtual methods for state change, buffer preparation, allocation etc, and they calling each other in an obscure recursive manner. This leads to fancy implicit bugs if you calling methods without understanding how they work and where they are implemented, which is impossible, since methods could be reimplemented later. > If we pretend that you did it, the question is how is it different from taking 'pred' as an argument in the functional example? How do I know that `decide_allocation` method is calling a method I'm going to reimplement? How do I know that decide_allocation would be reimplemented in some future decoder? In your example you explicitly redefining factorial. In my example I'm just redefining pred without caring about factorial and not even knowing that factorial calls pred (abstraction, remember?).

protomolecule 7y ago
"Non virtual methods has nothing to do with OOP, they are a mere sugar for function calling." By this logic virtual functions are mere sugar for tables of functions and as such have nothing to do with anything besides functions and tables. "We are talking about OOP, which is defined by late binding/open recursion" Oh, well, definition of OOP is a moving target, everyone defines it as they like, but when we are talking about trillion dollar mistakes, OOP certainly implies C++, Java, C# and such simply because Smalltalk and CLOS have been used on the far smaller scale. Having established this, I'm sure you would agree that saying that OOP prohibits or discourages non-virtual functions is unreasonable. It does introduce virtual functions, but like every tool, they shouldn't be abused. "a real world example" Looks like a poor approach to concurrency or an example of abuse of virtual functions, or both. "How do I know" Well, a method you are going to re-implement needs to have a clearly defined contract. If it doesn't, it is either not supposed to be reimplemented or the codebase is of poor quality. You can look at the set of virtual functions of a class as an interface. In the case of a plain interface you wouldn't ask 'how do I know how this interface is used?' - you don't and you can't, you just implement the contract. The same with re-implementation of virtual functions. "In your example you explicitly redefining factorial" No, I'm defining a new enhanced math function that reuses some existing code without understanding of its contract. Just like you do in your example :)
- ernst_klim 7y ago
  > Oh, well, definition of OOP is a moving target No, open recursion is the only thing that makes OOP a distinct paradigm. Without `self` you don't have OOP. [1] > No, I'm defining a new enhanced math function Yeah, no, you are redefining factorial in terms of different `pred` functions, and I'm simply defining `prev` without redefining factorial. [1] https://journal.stuffwithstuff.com/2013/08/26/what-is-open-recursion/ https://journal.stuffwithstuff.com/2013/08/26/what-is-open-r...
  - protomolecule 7y ago
    "No, open recursion is the only thing that makes OOP a distinct paradigm. Without `self` you don't have OOP." I'm not arguing that open recursion is part of OOP definition, I just disagree that C++ and C# aren't OOP since they have it as an opt-in feature. You yourself happened to mention encapsulation as part of OOP in your original comment. While you can call bundling data and functions together a sugar, limiting the scope of data to class' methods is essential. Consider implementation of a hash map. Isn't it nice that the state is accessible only to {contains, get, set}? After auditing these three functions you can be sure that the invariant is never violated. How would you ensure that in FP? Thanks for the link, I myself happened to explain the complexity of virtual function contracts in the same way, nice to have it written down in case I need it again.
    - andrenth 7y ago
      > Consider implementation of a hash map. Isn't it nice that the state is accessible only to {contains, get, set}? After auditing these three functions you can be sure that the invariant is never violated. How would you ensure that in FP? You can have the same with an abstract data type and a set of functions that operate on it. Only functions defined in the same module as the ADT can access its internals, so inspecting those functions would yield the same assurance you’d have in the OOP version. Arguably the FP version would be easier to inspect, because all data would be local (passed as a parameter), while the OOP version could have “semi-globals” in the form of instance variables.

protomolecule 7y ago

"Non virtual methods has nothing to do with OOP, they are a mere sugar for function calling." By this logic virtual functions are mere sugar for tables of functions and as such have nothing to do with anything besides functions and tables. "We are talking about OOP, which is defined by late binding/open recursion" Oh, well, definition of OOP is a moving target, everyone defines it as they like, but when we are talking about trillion dollar mistakes, OOP certainly implies C++, Java, C# and such simply because Smalltalk and CLOS have been used on the far smaller scale. Having established this, I'm sure you would agree that saying that OOP prohibits or discourages non-virtual functions is unreasonable. It does introduce virtual functions, but like every tool, they shouldn't be abused. "a real world example" Looks like a poor approach to concurrency or an example of abuse of virtual functions, or both. "How do I know" Well, a method you are going to re-implement needs to have a clearly defined contract. If it doesn't, it is either not supposed to be reimplemented or the codebase is of poor quality. You can look at the set of virtual functions of a class as an interface. In the case of a plain interface you wouldn't ask 'how do I know how this interface is used?' - you don't and you can't, you just implement the contract. The same with re-implementation of virtual functions. "In your example you explicitly redefining factorial" No, I'm defining a new enhanced math function that reuses some existing code without understanding of its contract. Just like you do in your example :)

ernst_klim 7y ago
> Oh, well, definition of OOP is a moving target No, open recursion is the only thing that makes OOP a distinct paradigm. Without `self` you don't have OOP. [1] > No, I'm defining a new enhanced math function Yeah, no, you are redefining factorial in terms of different `pred` functions, and I'm simply defining `prev` without redefining factorial. [1] https://journal.stuffwithstuff.com/2013/08/26/what-is-open-recursion/ https://journal.stuffwithstuff.com/2013/08/26/what-is-open-r...
- protomolecule 7y ago
  "No, open recursion is the only thing that makes OOP a distinct paradigm. Without `self` you don't have OOP." I'm not arguing that open recursion is part of OOP definition, I just disagree that C++ and C# aren't OOP since they have it as an opt-in feature. You yourself happened to mention encapsulation as part of OOP in your original comment. While you can call bundling data and functions together a sugar, limiting the scope of data to class' methods is essential. Consider implementation of a hash map. Isn't it nice that the state is accessible only to {contains, get, set}? After auditing these three functions you can be sure that the invariant is never violated. How would you ensure that in FP? Thanks for the link, I myself happened to explain the complexity of virtual function contracts in the same way, nice to have it written down in case I need it again.
  - andrenth 7y ago
    > Consider implementation of a hash map. Isn't it nice that the state is accessible only to {contains, get, set}? After auditing these three functions you can be sure that the invariant is never violated. How would you ensure that in FP? You can have the same with an abstract data type and a set of functions that operate on it. Only functions defined in the same module as the ADT can access its internals, so inspecting those functions would yield the same assurance you’d have in the OOP version. Arguably the FP version would be easier to inspect, because all data would be local (passed as a parameter), while the OOP version could have “semi-globals” in the form of instance variables.