Names are not type safety (2020)

Re:Names are not type safety (2020) by b_e_n_t_o_n on Monday August 04, 2025 @03:16AM (#44782878)

You can implement the Stringer interface for the type which prevents it from being logged and since it's private, code from outside of the module can't enumerate it. Of course it's still accessible via reflection or memory dumps etc, but isn't that the case with Java etc? Storing a plain text password like this is a bad idea anyways.

I guess my point is that a structural type system can still allow for encapsulation.

[ Parent | on HN ]

Re:Names are not type safety (2020) by lmm on Monday August 04, 2025 @04:02AM (#44783139)

> You can implement the Stringer interface for the type which prevents it from being logged and since it's private, code from outside of the module can't enumerate it.

Those sound like decidedly non-structural features. And couldn't you undermine them by passing it to a function that expects a different `struct { pw string }` and logs its contents?

[ Parent | on HN ]

Re:Names are not type safety (2020) by b_e_n_t_o_n on Tuesday August 05, 2025 @06:03AM (#44796211)

Only in the same module. Outside, it's effectively hidden.

And yeah, structurally typed languages often have nominal features. They come in useful in a lot of scenarios! Unless you're talking about something like Clojure which is not statically typed.

[ Parent | on HN ]