Structurally typed languages can still support information hiding.

   type PasswordString struct {
      pw string
   }
   func(p PasswordString) String(token string) { ... }

I guess the point is that you can model your domain using data as well as types.

▲ lmm 5 hours ago | parent [-]

> Structurally typed languages can still support information hiding.

But you haven't hidden the information, it's still a string. You can put the string in a wrapper struct but in a structural system that's not really any different from putting it a list or map - the data is still exposed, and if someone writes code to e.g. log objects by just enumerating all their fields (which is a very natural thing to do in those systems) then it will naturally print out your password and there's not really any way to make it ever not.

> I guess the point is that you can model your domain using data as well as types.

You want both in your toolbox though. Restricting yourself to only having types that are essentially lists, maps, or a handful of primitives has most of the same downsides as restricting yourself to not using types at all.

▲

b_e_n_t_o_n 4 hours ago | parent [-]

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.

	▲	lmm 4 hours ago \| parent [-]
		> 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?