I'm _begging_ you to please store non-primitive data in a struct or typed object rather than an arbitrary `key` => `value` store like a dictionary, hash table, or associative array
This even includes data that you get back from a third-party API. Take the extra couple of minutes to define the response properties in code rather than passing around an opaque bag of data
@tylerlwsmith I'm... Against this?
I think I agree on the principle but not the implementation.
I always whenever possible use only dictionaries, lists, strings, ints, floats, booleans, and null, exactly because then my data structures can be serialized, printed, understood, and hand-edited by default.
I do however agree that the keys used, their types, etc. need to be fully documented along with their meanings/behaviors. The languages (and crucially, docgen systems) that I use make this easy (TypedDict in Python and @/property in jsdoc).
In my (sometimes considered deranged) opinion organizing things into classes and methods is often a mistake.
The biggest actual benefit of this approach beyond serialization is that you design out shared data that would use pointers, which avoids entire classes of shared-state bugs.
@tiotasram I think so too. In particular, the experience with class-oriented programming* that led to Clojure’s design (and the decade+ of stability validating it) contradicts this approach.
That said, it’s also nuanced. Clojure provides protocols and records where named (maybe-typed) structure makes sense, but the norm is sets/maps/lists and it’s proven to be astoundingly robust.
*Java and C#, mainly, borrowing Jim Coplien’s terminology.
Tyler Smith
Sashin
Martin's Pipe Dreams
Tiota Sram
curtosis