3 ms·

> Anyone else have a similar experience? Exactly contrary. I find modelling in objects classes counter-intuitive and thus not good to reason about. When I pai

> Anyone else have a similar experience? Exactly contrary. I find modelling in objects classes counter-intuitive and thus not good to reason about. When I paint a wall I apply a function (paint) to the object (wall), not the object is painting itself. I can apply the same function to a different type (aka class) of object e.g. I can paint my chair. Stays the same function. So in my cognitive model of the world the objects are objects manipulated by me, not subjects executing "methods", but OOP is treating them as subjects.

kaba0 4y ago
Ok, let’s represent a double-ended stack then, as a circular buffer. It will be in the end a fixed sized array with a start and end variables pointing to one-one element of it. Doesn’t it inherently makes sense that I want to have a public API on top of it denoting how can it be used from the outside, while a private one, that encapsulates the implementation details, and makes them only callable by other methods of this object? This is the major point of OOP, in my opinion.
- menotyou 4y ago
  To get an API I just define a type for double-ended-stacks functions manipulating it. Or if you prefer to define it with immutable variables the functions accept an double-ended-stack and return a new copied and modified stack as result. The set of functions will be a moduls resembling what you call an API. I am not argue this can not be done on OOP, but I find it counter-intuitive and overly complex to do so.
shanebellone 4y ago
You can do the same thing with objects though. I have "utilities" which can be used with objects. Per your example, if object(wall) and object(chair) both share the attribute(color) then they both can utilize function(paint). The only prerequisite would that they are paintable.
- thesz 4y ago
  What you describe there is use of interfaces and properties. These things are much easier to reason about and to compose than classes with inheritance. For example, it is easy to solve Expression Problem [1] with interfaces and properties and it is hard to solve it with only classes and inheritance. [1] https://en.wikipedia.org/wiki/Expression_problem https://en.wikipedia.org/wiki/Expression_problem
  - shanebellone 4y ago
    "These things are much easier to reason about and to compose than classes with inheritance." Fair. Personally, that looks like an argument for objects rather than against. Do these concepts oppose or complement OOP? Is inheritance somehow a hidden requirement?
- menotyou 4y ago
  I did not say that it is not possible to do it. I said it is counterintuitive for me to express or model it in that way. And as you can see in the discussion arising, even this simple example is becoming a complex modelling problem in OOP.

kaba0 4y ago

Ok, let’s represent a double-ended stack then, as a circular buffer. It will be in the end a fixed sized array with a start and end variables pointing to one-one element of it. Doesn’t it inherently makes sense that I want to have a public API on top of it denoting how can it be used from the outside, while a private one, that encapsulates the implementation details, and makes them only callable by other methods of this object? This is the major point of OOP, in my opinion.

menotyou 4y ago
To get an API I just define a type for double-ended-stacks functions manipulating it. Or if you prefer to define it with immutable variables the functions accept an double-ended-stack and return a new copied and modified stack as result. The set of functions will be a moduls resembling what you call an API. I am not argue this can not be done on OOP, but I find it counter-intuitive and overly complex to do so.

shanebellone 4y ago

You can do the same thing with objects though. I have "utilities" which can be used with objects. Per your example, if object(wall) and object(chair) both share the attribute(color) then they both can utilize function(paint). The only prerequisite would that they are paintable.

thesz 4y ago
What you describe there is use of interfaces and properties. These things are much easier to reason about and to compose than classes with inheritance. For example, it is easy to solve Expression Problem [1] with interfaces and properties and it is hard to solve it with only classes and inheritance. [1] https://en.wikipedia.org/wiki/Expression_problem https://en.wikipedia.org/wiki/Expression_problem
- shanebellone 4y ago
  "These things are much easier to reason about and to compose than classes with inheritance." Fair. Personally, that looks like an argument for objects rather than against. Do these concepts oppose or complement OOP? Is inheritance somehow a hidden requirement?
menotyou 4y ago
I did not say that it is not possible to do it. I said it is counterintuitive for me to express or model it in that way. And as you can see in the discussion arising, even this simple example is becoming a complex modelling problem in OOP.