3 ms·

> Making everything an object is a cute idea but the fact of the matter is, most of the time data is just data, there's no associated behavior. Data is just ob

> Making everything an object is a cute idea but the fact of the matter is, most of the time data is just data, there's no associated behavior. Data is just objects that don't happen to have any behavior. You can look at it as there being a continuum between data and behavior: * Purely just storing raw uninterpreted bits in memory and letting anything read and poke at them. * Storing raw data in memory but having an API that ensures that the data is in a valid state and maintains invariants. * Encapsulating data behind an API that gives you flexibility to change the representation without breaking users. * Attaching additional behavior that happens to use that data directly to the type that stores the data. Object-oriented languages support the full continuum, but the language itself certainly doesn't require you to go all the way for every type. Different kinds of data and different domains will naturally fit certain points on this continuum. When you say, "There isn't a single OO codebase out there without POD objects", I consider that a feature of object-oriented languages: They are flexible enough to model a range of state/behavior policies.

dgb23 3y ago
I really like this this perspective but I think it’s more multi dimensional. Often data only needs to be read so new data can be produced. There’s no need for encapsulation here. If you want to ensure that you’re dealing with data that has certain properties then you can do that with types, schemas or simply read it. Encapsulation at a lower level is needed when you mutate state or otherwise own resources and possibly multiple things need to be updated in tandem. In this case you want operational semantics and not look at the innards of the data. So the interface you want describes behavior. And then there is another level where you only care about coordination of messages. The interface is not the data/state behind whoever produces or reads them. You don’t even care about behavior anymore.
sirwhinesalot 3y ago
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.

dgb23 3y ago

I really like this this perspective but I think it’s more multi dimensional. Often data only needs to be read so new data can be produced. There’s no need for encapsulation here. If you want to ensure that you’re dealing with data that has certain properties then you can do that with types, schemas or simply read it. Encapsulation at a lower level is needed when you mutate state or otherwise own resources and possibly multiple things need to be updated in tandem. In this case you want operational semantics and not look at the innards of the data. So the interface you want describes behavior. And then there is another level where you only care about coordination of messages. The interface is not the data/state behind whoever produces or reads them. You don’t even care about behavior anymore.

sirwhinesalot 3y ago

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.