3 ms·

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 th

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

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.