4 ms·

A great, and often under-appreciated point is - as put by Guy Steele - "We find that the notion of side effect and the notion of equality (object identity) are

by kaba0 3y ago

A great, and often under-appreciated point is - as put by Guy Steele - "We find that the notion of side effect and the notion of equality (object identity) are mutually constraining; to define one is to define the other." With that in mind, I do believe that objects, as in encapsulating some kind of side-effect, is a very good model. But it is not a replacement for everything - a more data-oriented approach makes much more sense for some other parts of a program. Multiple views are absolutely possible within the same language/program, and should in general be the preferred way.

cmrdporcupine 3y ago
What I would like to see is a system where object-orientation is emergent from a more set-oriented/relational model. I haven't put my finger on what exactly this is yet, but maybe it's something like "methods" really being a kind of predicate-dispatch over matching tuples. So a "class" (and object identity) is really telling the system: when you see attributes X, Y, Z bundled together as a result of a query, here is a set of behaviors that you can apply on those tuples.
- kaba0 3y ago
  I don't know, relational model seems to be fundamentally mathematical/side-effect free. Like, I think we should think of a `Connection` as an object, not `User`, which is just plain data.
  - cmrdporcupine 3y ago
    I get your point, but ... updates on tuples are definitely a "thing" in a relational system... and the set of connections and their attributes and state can be modeled in relations quite easily... Not sure I see a conflict.
    - kaba0 3y ago
      Fair enough, though I think a functional approach (you create a new set from the old, with one field changed), and somehow “committing” it back is fine, and no need for side effecting then (besides at the boundary). Maybe structural typing is somewhat similar to what you think of? Probably typescript, maybe go are the most well-known for this out of the statically typed ones, but clojure is also all about every “object” being a key-value map.
      - cmrdporcupine 3y ago
        Yeah, a functional approach is fine. In reality you can think of an "update" to a tuple in a relation as a "replace this relation-valued variable with a new one where this tuple has been modified." And so mutations to base relations ("tables" in SQL parlance) just means changing the value of that relation in in the global shared, named base relation list. And if you use a persistent data structure behind the scene, and do CoW etc, you can even probably make this relatively efficient... And I don't think it's so much structural typing, as it is defining method/function dispatch off predicate matches. More.. structural values? Clumsily: Disconnect(connection_id) = with project ConnectionState CS where CS.Id = connection_id { if CS.state != 'connected Raise('not_connected) else CS.state = 'disconnected }
        senderista 3y ago
        Mutating a tuple in a relation doesn't really make sense per se, because a relation is just a subset of the cartesian product of its attribute domains, and only value-based semantics apply to sets. What does make sense is identifying a primary key for a relation, deleting a tuple, and inserting another tuple with the same primary key but different values of its other attributes. In practice, of course, this is equivalent to in-place mutation of identity-objects corresponding to unique values of the primary key.

by kaba0 3y ago

cmrdporcupine 3y ago

What I would like to see is a system where object-orientation is emergent from a more set-oriented/relational model. I haven't put my finger on what exactly this is yet, but maybe it's something like "methods" really being a kind of predicate-dispatch over matching tuples. So a "class" (and object identity) is really telling the system: when you see attributes X, Y, Z bundled together as a result of a query, here is a set of behaviors that you can apply on those tuples.

kaba0 3y ago
I don't know, relational model seems to be fundamentally mathematical/side-effect free. Like, I think we should think of a `Connection` as an object, not `User`, which is just plain data.
- cmrdporcupine 3y ago
  I get your point, but ... updates on tuples are definitely a "thing" in a relational system... and the set of connections and their attributes and state can be modeled in relations quite easily... Not sure I see a conflict.
  - kaba0 3y ago
    Fair enough, though I think a functional approach (you create a new set from the old, with one field changed), and somehow “committing” it back is fine, and no need for side effecting then (besides at the boundary). Maybe structural typing is somewhat similar to what you think of? Probably typescript, maybe go are the most well-known for this out of the statically typed ones, but clojure is also all about every “object” being a key-value map.
    - cmrdporcupine 3y ago
      Yeah, a functional approach is fine. In reality you can think of an "update" to a tuple in a relation as a "replace this relation-valued variable with a new one where this tuple has been modified." And so mutations to base relations ("tables" in SQL parlance) just means changing the value of that relation in in the global shared, named base relation list. And if you use a persistent data structure behind the scene, and do CoW etc, you can even probably make this relatively efficient... And I don't think it's so much structural typing, as it is defining method/function dispatch off predicate matches. More.. structural values? Clumsily: Disconnect(connection_id) = with project ConnectionState CS where CS.Id = connection_id { if CS.state != 'connected Raise('not_connected) else CS.state = 'disconnected }
      - senderista 3y ago
        Mutating a tuple in a relation doesn't really make sense per se, because a relation is just a subset of the cartesian product of its attribute domains, and only value-based semantics apply to sets. What does make sense is identifying a primary key for a relation, deleting a tuple, and inserting another tuple with the same primary key but different values of its other attributes. In practice, of course, this is equivalent to in-place mutation of identity-objects corresponding to unique values of the primary key.