4 ms·

You don't need OO for state management. Plain data structures and functions work just fine. The core aspects of OO like inheritance are not that useful for mo

You don't need OO for state management. Plain data structures and functions work just fine. The core aspects of OO like inheritance are not that useful for most problems.

threatofrain 2y ago
IMO inheritance is more syntactical QoL than core. That’s just code DRY stuff and composition is fine for that too. The architectural elements of OO are state machine modeling (encapsulation) and message passing.
- lispm 2y ago
  The Common Lisp Object System does not use message passing.
  - TuringTest 2y ago
    It does have method dispatching, which is the same beast with a different name.
    - _19qg 2y ago
      Message passing means that objects communicate only via messages with some payload. There is a sender and a receiver. Possibly there are many receivers in a broadcast message. Messages will run synchronous or asynchronous. The receiver decides what to do with the message and how to interpret it. If it does not understand the message, it can forward the message via inheritance, delegation or similar. The message implementation belongs to the class and/or object. There is a syntax for sending messages. The mental model of a developer is based on communicating objects. In Common Lisp the object system uses generic functions, which assemble several related methods. Generic Functions are defined outside (!) of classes and objects. Generic Functions are both CLOS objects and functions. Generic functions are called with one or more arguments. The Generic Function decides which methods are run and in what combination. There is no equivalent to a receiver: CLOS generic functions dispatch over its arguments, all primary arguments. There is no equivalent of a privileged receiver object or a self. There is no special syntax for calling a generic function and they are themselves first class objects, which can be stored and passed around. The mental model of a developer is based on function calling of runtime assembled functions.
taylodl 2y ago
> You don't need OO for state management. Of course you don't, that's why I said OO is most likely the way to go. I also spoke of more than simple state management - If you're modeling a system having several interacting entities whose interactions may vary based off that entity's current state - isn't simple state management. You still don't have to go OO to solve that problem, it's just a very good choice in most circumstances. Also, inheritance is not a core aspect of OO. It's a common aspect of OO and even a popular aspect, but it's not core. To wit, there are OO systems not having inheritance.
- lispm 2y ago
  > not a core aspect of OO One of the core aspects of OO is reuse of functionality, typically by inheritance or delegation. We can find one or both in most OO languages.
  - taylodl 2y ago
    I wouldn't say reuse of functionality is a core aspect of OO, but I will say that's a core reason why OO was so heavily adopted in the 90s. It's mind-numbing to recall how much time and money was wasted on making things "reusable" only to never be reused.
    - lispm 2y ago
      > I wouldn't say reuse of functionality is a core aspect of OO You'll find it in practically every object-oriented language, starting with Simula. Later Smalltalk, Actors, CLOS, C++, Self, Java, Objective-C, Python, JavaScript, ... > making things "reusable" only to never be reused. It's similar mind-numbing how much has been reused.
      - taylodl 2y ago
        > It's similar mind-numbing how much has been reused. My experience is the reuse comes from frameworks. I'd love to hear if you've had another experience.

You don't need OO for state management. Plain data structures and functions work just fine. The core aspects of OO like inheritance are not that useful for most problems.

threatofrain 2y ago

IMO inheritance is more syntactical QoL than core. That’s just code DRY stuff and composition is fine for that too. The architectural elements of OO are state machine modeling (encapsulation) and message passing.

lispm 2y ago
The Common Lisp Object System does not use message passing.
- TuringTest 2y ago
  It does have method dispatching, which is the same beast with a different name.
  - _19qg 2y ago
    Message passing means that objects communicate only via messages with some payload. There is a sender and a receiver. Possibly there are many receivers in a broadcast message. Messages will run synchronous or asynchronous. The receiver decides what to do with the message and how to interpret it. If it does not understand the message, it can forward the message via inheritance, delegation or similar. The message implementation belongs to the class and/or object. There is a syntax for sending messages. The mental model of a developer is based on communicating objects. In Common Lisp the object system uses generic functions, which assemble several related methods. Generic Functions are defined outside (!) of classes and objects. Generic Functions are both CLOS objects and functions. Generic functions are called with one or more arguments. The Generic Function decides which methods are run and in what combination. There is no equivalent to a receiver: CLOS generic functions dispatch over its arguments, all primary arguments. There is no equivalent of a privileged receiver object or a self. There is no special syntax for calling a generic function and they are themselves first class objects, which can be stored and passed around. The mental model of a developer is based on function calling of runtime assembled functions.

taylodl 2y ago

> You don't need OO for state management. Of course you don't, that's why I said OO is most likely the way to go. I also spoke of more than simple state management - If you're modeling a system having several interacting entities whose interactions may vary based off that entity's current state - isn't simple state management. You still don't have to go OO to solve that problem, it's just a very good choice in most circumstances. Also, inheritance is not a core aspect of OO. It's a common aspect of OO and even a popular aspect, but it's not core. To wit, there are OO systems not having inheritance.

lispm 2y ago
> not a core aspect of OO One of the core aspects of OO is reuse of functionality, typically by inheritance or delegation. We can find one or both in most OO languages.
- taylodl 2y ago
  I wouldn't say reuse of functionality is a core aspect of OO, but I will say that's a core reason why OO was so heavily adopted in the 90s. It's mind-numbing to recall how much time and money was wasted on making things "reusable" only to never be reused.
  - lispm 2y ago
    > I wouldn't say reuse of functionality is a core aspect of OO You'll find it in practically every object-oriented language, starting with Simula. Later Smalltalk, Actors, CLOS, C++, Self, Java, Objective-C, Python, JavaScript, ... > making things "reusable" only to never be reused. It's similar mind-numbing how much has been reused.
    - taylodl 2y ago
      > It's similar mind-numbing how much has been reused. My experience is the reuse comes from frameworks. I'd love to hear if you've had another experience.