3 ms·
And in Go since there is no parametric polymorphism you would end up writing either: 1) Methods with names that indicate the parameter types. 2) Method calls o
by 4ydx 12y ago
And in Go since there is no parametric polymorphism you would end up writing either:
1) Methods with names that indicate the parameter types.
2) Method calls on objects to convert some internal struct data from one type to another.
3) Something I haven't thought of that doesn't involve losing a handle on your type.
So there is certainly a loss in convenience, but if you use the type system it can be just as safe as a functional language as far as I can tell. So, yeah, it isn't as intellectually elegant, but it also isn't really that hard to deal with.
- ufo 12y agoNo you can't. The point of generics is that you don't need to specify the parameter types - the parameter type is also a parameter. This means that you can write type safe container operations like "map" and "filter". The only way to write this kind of generic code in Go is to cast everything to `interface{}`, which can't be checked statically. If you are still not convinced, one of the things you can do with generics is say "these two parameters have the same type". In Go the best you can do is say "these two parameters are subclasses of something", which is less precise.
- 4ydx 12y agoYeah I follow you. I am providing ways of trying to work around the lack of a higher level type class system. As a baseline, I would recommend not jumping outside golang's given type system just because it feels inconvenient for the programmer. That means you don't get to write a generic method for, for instance, all integers. Too bad :P This means the programmer does have to do more work, but the type system is always strictly enforced. That is better in my opinion.