This week, I was trying to rewrite the inheritance checker for generics. The inheritance checker is the compiler pass which makes sure that there aren’t any problems with overridden methods, and that only abstract classes can have abstract methods.<\/p>\n
The question I was faced with was: Can something inherit from the same generic interface twice, with different type arguments? For example:<\/p>\n
interface Processor<T>\r\n{\r\n void process(T t);\r\n}\r\nclass MultiProcessor implements Processor<int>, Processor<string>\r\n{\r\n void process(int i) {}\r\n void process(string s) {}\r\n}<\/pre>\nThis makes conceptual sense, and doesn’t have any ambiguities, so it really should be allowed. Unfortunately, there are two problems that can arise if this is allowed. The first is with the low-level implementation of method overriding, which can be changed; but the second is an ambiguity that can’t be solved without substantial changes to the language. Here’s an example that should illustrate the second problem:<\/p>\n
interface List<T>\r\n{\r\n void add(T t);\r\n T get(uint index);\r\n uint size();\r\n}\r\nclass MultiList implements List<int>, List<string>\r\n{\r\n void add(int i) { ... }\r\n void add(string s) { ... }\r\n int get(uint index) { ... }\r\n string get(uint index) { ... }\r\n \/\/ what about size()?\r\n}<\/pre>\nMultiList<\/code> tries to be two different lists at the same time. The add()<\/code> and get()<\/code> methods should work fine, because they have different signatures (in plinth, the return type is part of a method’s signature). However, the size()<\/code> method has the same signature no matter which list it is from. Obviously we don’t want both lists to have the same implementation of size()<\/code> – we might have 2 ints and 7 strings. In order for everything to still work when we cast from MultiList<\/code> to List<int><\/code> or List<string><\/code>, we need to have two different implementations.<\/p>\nBut with the current system, if you override a method, it overrides all of the super-type methods with the same signature, making it impossible to have two different size()<\/code> implementations. The solution is to change the language to allow methods to be hidden instead of overridden.\u00a0For the unfamiliar, here’s a quick description of the difference:<\/p>\n\n- Hiding is what happens to fields: when you make a new one with the same name in a subtype, the one in the supertype still exists, but you can’t access it from the subtype (if you need to access it, you can cast to the supertype first and access it there).<\/li>\n
- Overriding is what happens to methods: when you make a new one with the same signature in a subtype, the one in the supertype gets overwritten with your new one, so that everywhere you access it you are referring to the same thing.<\/li>\n<\/ul>\n
What we actually need to do to solve this sort of problem is to hide a method while providing an implementation for it, i.e. override it and hide it at the same time. We could provide implementations for both size()<\/code> methods to do different things, and then hide one (or both) of them, so that you get two different answers when you do:<\/p>\n(cast<List<int>> multi).size()\r\n(cast<List<string>> multi).size()<\/pre>\n