8 ms·

I am also very interested in how this work in practice. With OOP at least you know the shape of your data structure as opposed to the hash map as a mere contain

I am also very interested in how this work in practice. With OOP at least you know the shape of your data structure as opposed to the hash map as a mere container type.

akavi 2y ago
You can get strongly typed "shaped" data without objects[0], even in Java: Records[1]. ~Unfortunately, I believe they're mutable (and cannot be made immutable).~ Edit: I was wrong, they're immutable. [0]: I'm using "object" to mean "data bound to methods", since the concept of aggregate data in general long pre-date OOP (eg, C's structs) [1]: https://docs.oracle.com/en/java/javase/17/language/records.html https://docs.oracle.com/en/java/javase/17/language/records.h...
- bedatadriven 2y ago
  A record's fields are final, so records are immutable (though they can include immutable pointers to mutable objects)
- taftster 2y ago
  Java Records are immutable (by the most common definition). They don't have any means to update the record (via setters, etc.) after construction. That doesn't mean, for example, you can't store a reference to a mutable type (for example, a List or Map) in your record. The frustration I have with Records is there is no good way to prevent direct construction of them. That is, the constructor is public, which prevents an easy way of enforcing an invariant during construction. For example, let's say that you have a record with a Date type. There's no good way to prevent a user from creating the record with an invalid date, one that is out of a needed date range. Or maybe enforcing a field cannot be null or some combination of fields must meet requirements as a group. The benefit I get from the classic Builder pattern is defeated with Records. I can't enforce checking of my fields before the construction of the record object itself. Presumably I would need to verify the object after construction, which is unfortunate.
  - akavi 2y ago
    Can you make the Record class private to a module, and only export a static function that constructs them? (I know very little about Java)
    - kaba0 2y ago
      To a degree, yes, that’s possible. But leaking a private type over module boundaries is bad form, so a better (though possibly over engineered solution) would be to have a separate public interface, implemented by the private record type, and the static function would have that interface as return type.
      - enugu 2y ago
        Why is it bad form to expose a record type only via custom functions and not its field accessors? Isn't this just like exposing a more usual object with its public functions and private functions remain inaccessible?
  - vips7L 2y ago
    You can enforce some invariants during construction: record Point(int x, int y) { Point { if (x < 0) throw new IllegalArgumentException() } } or if you want to assert something is not null: record Person(String name) { Person { requireNonNull(name); } }
    - nogridbag 2y ago
      I think records will be much more useful if https://openjdk.org/jeps/468 https://openjdk.org/jeps/468 gets out of preview.
  - snmx999 2y ago
    You can create dedicated, already verified objects to pass on to your record. E.g. AllowedDate (extends Date).
  - 2y ago
geophile 2y ago
I am an OOP programmer going back to the late 80s (including the cfront days of C++), and a serious user of Python since 2007. In Python, I sometimes try data-oriented programming, using lists and dicts to structure data. And I find that it does not work well. Once I get two or more levels of nesting, I find it far too easy to get confused about which level I'm on, which is not helped by Python's lack of strong typing. In these situations, I often introduce objects that wrap the map or dict, and have methods that make sense for that level. In other words, the objects can be viewed as providing clear documentation for the whole nested structure, and how it can be navigated.
- deleted 2y ago
  [deleted]
- goostavos 2y ago
  >Once I get two or more levels of nesting, I find it far too easy to get confused about which level I'm on Author here, I agree with you. I have the working memory of a small pigeon. The flavor of data orientation we cover in the book leverages strongly typed representations of data (as opposed to using hash maps everywhere). So you'll always know what's shape it's in (and the compiler enforces it!). We spend a lot of time exploring the role that the type system can play in our programming and how we represent data.
  - joshlemer 2y ago
    Given the strongly typed flavour of data oriented programming, I wonder if you have any thoughts on the "proliferation of types" problem. How to avoid, especially in a nominally typed language like Java, an explosion of aggregate types for every context where there may be a slight change in what fields are present, what their types are, and which ones are optional. Basically, Rich Hickey's Maybe Not talk. record Make(makeId, name) record Model(modelId, name) record Car(make, model, year) record Car(makeId, modelId, year) record Car(make, model) record Car(makeId, modelId) record Car(make, year) record Car(makeId, year) record Car(make, model, year, colour) record Car(makeId, modelId, year, colour) record Car(year, colour) ....
kccqzy 2y ago
Clojure has spec. That allows you to know a specification of what the data structure contains.
davedx 2y ago
With TypeScript you have types to tell you the shape of your data.

I am also very interested in how this work in practice. With OOP at least you know the shape of your data structure as opposed to the hash map as a mere container type.

akavi 2y ago

You can get strongly typed "shaped" data without objects[0], even in Java: Records[1]. ~Unfortunately, I believe they're mutable (and cannot be made immutable).~ Edit: I was wrong, they're immutable. [0]: I'm using "object" to mean "data bound to methods", since the concept of aggregate data in general long pre-date OOP (eg, C's structs) [1]: https://docs.oracle.com/en/java/javase/17/language/records.html https://docs.oracle.com/en/java/javase/17/language/records.h...

bedatadriven 2y ago
A record's fields are final, so records are immutable (though they can include immutable pointers to mutable objects)
taftster 2y ago
Java Records are immutable (by the most common definition). They don't have any means to update the record (via setters, etc.) after construction. That doesn't mean, for example, you can't store a reference to a mutable type (for example, a List or Map) in your record. The frustration I have with Records is there is no good way to prevent direct construction of them. That is, the constructor is public, which prevents an easy way of enforcing an invariant during construction. For example, let's say that you have a record with a Date type. There's no good way to prevent a user from creating the record with an invalid date, one that is out of a needed date range. Or maybe enforcing a field cannot be null or some combination of fields must meet requirements as a group. The benefit I get from the classic Builder pattern is defeated with Records. I can't enforce checking of my fields before the construction of the record object itself. Presumably I would need to verify the object after construction, which is unfortunate.
- akavi 2y ago
  Can you make the Record class private to a module, and only export a static function that constructs them? (I know very little about Java)
  - kaba0 2y ago
    To a degree, yes, that’s possible. But leaking a private type over module boundaries is bad form, so a better (though possibly over engineered solution) would be to have a separate public interface, implemented by the private record type, and the static function would have that interface as return type.
    - enugu 2y ago
      Why is it bad form to expose a record type only via custom functions and not its field accessors? Isn't this just like exposing a more usual object with its public functions and private functions remain inaccessible?
- vips7L 2y ago
  You can enforce some invariants during construction: record Point(int x, int y) { Point { if (x < 0) throw new IllegalArgumentException() } } or if you want to assert something is not null: record Person(String name) { Person { requireNonNull(name); } }
  - nogridbag 2y ago
    I think records will be much more useful if https://openjdk.org/jeps/468 https://openjdk.org/jeps/468 gets out of preview.
- snmx999 2y ago
  You can create dedicated, already verified objects to pass on to your record. E.g. AllowedDate (extends Date).
- 2y ago

geophile 2y ago

I am an OOP programmer going back to the late 80s (including the cfront days of C++), and a serious user of Python since 2007. In Python, I sometimes try data-oriented programming, using lists and dicts to structure data. And I find that it does not work well. Once I get two or more levels of nesting, I find it far too easy to get confused about which level I'm on, which is not helped by Python's lack of strong typing. In these situations, I often introduce objects that wrap the map or dict, and have methods that make sense for that level. In other words, the objects can be viewed as providing clear documentation for the whole nested structure, and how it can be navigated.

deleted 2y ago
[deleted]
goostavos 2y ago
>Once I get two or more levels of nesting, I find it far too easy to get confused about which level I'm on Author here, I agree with you. I have the working memory of a small pigeon. The flavor of data orientation we cover in the book leverages strongly typed representations of data (as opposed to using hash maps everywhere). So you'll always know what's shape it's in (and the compiler enforces it!). We spend a lot of time exploring the role that the type system can play in our programming and how we represent data.
- joshlemer 2y ago
  Given the strongly typed flavour of data oriented programming, I wonder if you have any thoughts on the "proliferation of types" problem. How to avoid, especially in a nominally typed language like Java, an explosion of aggregate types for every context where there may be a slight change in what fields are present, what their types are, and which ones are optional. Basically, Rich Hickey's Maybe Not talk. record Make(makeId, name) record Model(modelId, name) record Car(make, model, year) record Car(makeId, modelId, year) record Car(make, model) record Car(makeId, modelId) record Car(make, year) record Car(makeId, year) record Car(make, model, year, colour) record Car(makeId, modelId, year, colour) record Car(year, colour) ....

kccqzy 2y ago

Clojure has spec. That allows you to know a specification of what the data structure contains.

davedx 2y ago

With TypeScript you have types to tell you the shape of your data.