News for hackers. Stuff that matters.
Re:Names are not type safety (2020) by stirfish on Sunday August 03, 2025 @10:40PM (#44781644)
> should just work if it has the correct fields.

Correct fields by...name? By structure? I'm trying to understand.

Re:Names are not type safety (2020) by b_e_n_t_o_n on Sunday August 03, 2025 @10:46PM (#44781675)
By name, type, and structure. In typescript for example:

   let full_name = (in: { first: string, last: string }) => in.first + " " + in.last
Then you can use this function on any data type that satisfies that signature, regardless of if it's User, Dog, Manager etc.
Re:Names are not type safety (2020) by tsimionescu on Monday August 04, 2025 @02:23AM (#44782624)
This is very much backwards from most programming practices. It's much more common to have an operation that makes sense for many structurally different types, such as add(a, b) where a and b could be integers, floating point numbers, complex numbers, 3D vectors, 4D vectors, matrices etc.
Re:Names are not type safety (2020) by b_e_n_t_o_n on Monday August 04, 2025 @02:30AM (#44782668)
Most programming happens in nominally typed languages where the above isn't trivially possible. To be fair that example is contrived, but you can imagine operations happening on large dicts where only a small subset of the fields are necessary.
Re:Names are not type safety (2020) by tsimionescu on Monday August 04, 2025 @05:12AM (#44783484)
This is actually a relatively common example of the benefits of either polymorphism (for the a.add(b) version) or generic methods/templates. You'll actually find libraries that have a method or template function like this in C++, Java, C#, and other commonly used static languages.