3 ms·

An object without behavior is not an object, it's a self-contradictory statement. Objects are a pattern that appears in all languages (if you are implementing

An object without behavior is not an object, it's a self-contradictory statement. Objects are a pattern that appears in all languages (if you are implementing a plugin API of any sort you need to have hidden data and a shared interface). A language having OO features only makes this easier. Same with FP, you can do OO and FP in C, all FP means is that your functions don't have hidden side effects. If you make a Point class with getters and setters for its internal data, you've just emulated a record type in a really dumb and inefficient way. The whole "you could replace the internal representation with polar coordinates" example never ever happens.

int_19h 3y ago
An object without behavior is simply an object with zero methods. You don't have to treat that as a special case in any way. Historically, Simula-67 replaced records (in competing derivatives of Algol 60) with classes, precisely because it was clear to the designers that an object is a fundamentally different thing. And yes, of course nobody actually does this kind of thing with Point. The whole Java-style getX/setY business was never what OO is about. A well-designed OO language shouldn't make you encapsulate data until the moment you actually need non-record-like behavior.
- sirwhinesalot 3y ago
  Have you ever heard the expression "a rose by any other name would smell just as sweet"? Contorted to programming it means syntax and semantics are different things and changing the syntax does not change the semantics. In the case of objects, lets say I agree with you that an object with no behavior or an object with no data are still (semantically) objects. What then, isn't an object? Am I doing object-oriented programming if my program is a set of objects with no data and a single non-virtual "run" method (semantically functions) being applied to objects with no behavior (semantically records)? You see my point? Yes you can model functions and records (syntactically) with objects but are they actually (semantically) objects? If I can do "object-oriented programming" in C which has no class keyword to speak of, what am I creating? I'm building (semantic) objects out of (syntactic) combinations of structs of function pointers (semantically interfaces) that accept a void* "this" parameters (needed to encapsulate the object's internal data). In haskell (a purely functional programming language) the main function returns IO (), a monad representing an imperative computation. The language itself, conceptually, never executes this monad, the environment does, so it's "pure". But that's just a cute trick, main is an imperative procedure no matter the tricks the language uses to hide this fact. A (semantic) object is a representation of some concept (abstraction) with its own internal data (encapsulation) that can respond as it wishes to a set of messages (polymorphism). You are only programming in an object-oriented style if the majority of your code is built out of such objects. Inheritance used to be part of the family and is often still taught as being a core component of object oriented programming but it's widely regarded as a terrible idea these days and you can certainly program in an object-oriented style without ever modelling an inheritance relationship.
  - int_19h 3y ago
    Whether to treat records as objects with null behavior, or to treat objects as records with behavior, is a matter of perspective. Both definitions are equivalent for all practical purposes. To me, what makes an object fundamentally distinct from a record is the notion of object identity + dynamic dispatch based on the same (encapsulation is an optional feature). Now you might say that an object with only data fields doesn't do dynamic dispatch, but that really depends on the language - e.g. in Eiffel, fields can be replaced with methods without breaking clients precisely because the dispatch is always dynamic. Thus every data object is polymorphic, even if that polymorphism is mostly unused in practice. C# still has the distinction, but it's so blurred with auto-properties that it can be treated largely the same. The Java dance with manual get/set to enable polymorphism is IMO rather an indicator that it is not a well-designed OO language - and it is very regrettable that it popularized this hack as "what OO is about". I also don't think that sensible OOD requires the "everything is an object" mentality in terms that you describe. Indeed, even in the purest OO languages like Smalltalk, e.g. arguments are passed effectively as a tuple, so it still has the concept of plain data that methods pass around and return - it can't be methods all the way down. Making those tuples explicit doesn't fundamentally change anything.

int_19h 3y ago

An object without behavior is simply an object with zero methods. You don't have to treat that as a special case in any way. Historically, Simula-67 replaced records (in competing derivatives of Algol 60) with classes, precisely because it was clear to the designers that an object is a fundamentally different thing. And yes, of course nobody actually does this kind of thing with Point. The whole Java-style getX/setY business was never what OO is about. A well-designed OO language shouldn't make you encapsulate data until the moment you actually need non-record-like behavior.

sirwhinesalot 3y ago
Have you ever heard the expression "a rose by any other name would smell just as sweet"? Contorted to programming it means syntax and semantics are different things and changing the syntax does not change the semantics. In the case of objects, lets say I agree with you that an object with no behavior or an object with no data are still (semantically) objects. What then, isn't an object? Am I doing object-oriented programming if my program is a set of objects with no data and a single non-virtual "run" method (semantically functions) being applied to objects with no behavior (semantically records)? You see my point? Yes you can model functions and records (syntactically) with objects but are they actually (semantically) objects? If I can do "object-oriented programming" in C which has no class keyword to speak of, what am I creating? I'm building (semantic) objects out of (syntactic) combinations of structs of function pointers (semantically interfaces) that accept a void* "this" parameters (needed to encapsulate the object's internal data). In haskell (a purely functional programming language) the main function returns IO (), a monad representing an imperative computation. The language itself, conceptually, never executes this monad, the environment does, so it's "pure". But that's just a cute trick, main is an imperative procedure no matter the tricks the language uses to hide this fact. A (semantic) object is a representation of some concept (abstraction) with its own internal data (encapsulation) that can respond as it wishes to a set of messages (polymorphism). You are only programming in an object-oriented style if the majority of your code is built out of such objects. Inheritance used to be part of the family and is often still taught as being a core component of object oriented programming but it's widely regarded as a terrible idea these days and you can certainly program in an object-oriented style without ever modelling an inheritance relationship.
- int_19h 3y ago
  Whether to treat records as objects with null behavior, or to treat objects as records with behavior, is a matter of perspective. Both definitions are equivalent for all practical purposes. To me, what makes an object fundamentally distinct from a record is the notion of object identity + dynamic dispatch based on the same (encapsulation is an optional feature). Now you might say that an object with only data fields doesn't do dynamic dispatch, but that really depends on the language - e.g. in Eiffel, fields can be replaced with methods without breaking clients precisely because the dispatch is always dynamic. Thus every data object is polymorphic, even if that polymorphism is mostly unused in practice. C# still has the distinction, but it's so blurred with auto-properties that it can be treated largely the same. The Java dance with manual get/set to enable polymorphism is IMO rather an indicator that it is not a well-designed OO language - and it is very regrettable that it popularized this hack as "what OO is about". I also don't think that sensible OOD requires the "everything is an object" mentality in terms that you describe. Indeed, even in the purest OO languages like Smalltalk, e.g. arguments are passed effectively as a tuple, so it still has the concept of plain data that methods pass around and return - it can't be methods all the way down. Making those tuples explicit doesn't fundamentally change anything.