3 ms·
> Still, I'd suggest having a "user" that knows how to render itself as a string is better than passing around the user's name or something as a string everywhe
by schwartzworld 4y ago
> Still, I'd suggest having a "user" that knows how to render itself as a string is better than passing around the user's name or something as a string everywhere and expecting every bit of code that needs to do some user-object-method-y thing to have to look it up themselves.
For some reason this seems to be the best kept secret in software development. Type-driven development lives somewhere at the intersection of OOP and FP. Here on HN every time TypeScript comes up, people claim to prefer code comments or some other nonsense that doesn't give you any of the benefits, because they see types as (userName: string, userAge: number) and not User { name: string, age: number }
- kroltan 4y agoYes, type-driven development saves so much hassle, both in ingesting user-provided data (parsing request bodies etc) as well as limiting the API surface of what you can do to things. Sadly, one very useful feature is missing from most languages, and that is, the ability to make opaque or partially transparent wrapper types. For example in C# before record types, you'd need about 30 lines of boilerplate if you wanted to make a wrapper for an identifier that can only be compared for equality. Wrapper and rich types allow writing shared behaviours for those specific kinds of information, and greatly reduce the "accidental API surface" of primitive types that plagues us with so many bugs and data leaks.