4 ms·
It's hard to articulate but whenever I find myself wishing I could inherit methods in a wrapper type, the design is bad. The designs where it ends up not being
by xyzzy_plugh 4y ago
It's hard to articulate but whenever I find myself wishing I could inherit methods in a wrapper type, the design is bad. The designs where it ends up not being necessary are always much friendlier.
- saghm 4y agoYeah, I don't think I disagree there. If you want to automatically delegate methods, you can always use a type alias, and if you want to have delegation but type strictness (i.e. not having the alias and the original being interchangeable), you can do it manually. I think the two things here that I personally don't prefer are not having some way to opt into delegation (e.g. the `Deref`/`DerefMut` traits in Rust) and the more general paradigm of interfaces being implicit (which if I understand correctly is why it would be ambiguous about whether the wrapper types implemented the same interfaces as the wrapped type), but those are much larger philosophical differences. If you do want interfaces and wrapper types to work the way they do in Go, I agree that having a method for length would probably be less consistent with the design philosophy. I do feel like the FAQ could be a bit more explicit about the rationale though; most people who read that page and have that question aren't going to as experienced in Go, so they aren't as likely to read "interfaces on basic types" and go "aha, yes, that would be weird with wrapper types!". That said, I also don't really use Go at all due to the philosophical differences I mentioned above, so maybe my reading isn't going to be representative of their target audience anyhow.