Just to add a bit more exposition... We wouldn't want a call of "dispatch_" to pass a static type check if the argument was 4.5 (unless we happened to have yet another definition for floats). However, if we try to reason that "class a" and "class b" are the only subtypes of "abstract class" and allow "dispatch_" to be sent to an argument typed as "abstract class", then what happens if we define "class c" as yet another subtype of "abstract class"? Surely we wouldn't expect the previously accepted call site to be retroactively rejected. Therefore we should reject it when we don't have a method definition specifically for "abstract class". An abstract method definition simply tells the compiler that we expect non-abstract specializations to override the method. Basically saying "If you call this and it fails at runtime, it's the fault of whoever created the subtype, not whoever wrote the call site.".
We've considered adding the notion of a type coverage, where we assert that all possible instances of a type "abstract class" logically must fall under either class a or class b or class c. For example, the three subclasses could be specializations of the abstract class in such a way that some field is defined as integer in the abstract class, (∞..-1] in class a, [0..0] in class b, and [1..∞) in class c. We can see that the three classes "cover" the abstract class — there are no instances of the abstract class that aren't also an instance of class a, class b, or class c. Note, however, that there may be additional subclasses of the abstract class that are not subclasses of those three. For example, the class for which that field has the type [0..∞) is actually a subtype of the abstract class, but is a supertype of both class b and class c. Additionally, the class whose field has the type [-5..5] is a subtype of the abstract type, but is actually incomparable (neither a subtype not supertype) with class a, class b, and class c. So type coverages are hard to make (1) right, and (2) useful, even for something as seemingly simple as integer ranges. I believe they're not likely to show up in the type system for quite a long time, if ever (the level two optimizer, on the other hand, should be able to leverage this kind of integer range coverage analysis at some point). > On May 23, 2014, at 3:11 PM, Robbert van Dalen <[email protected]> > wrote: > > Todd, > >> Sorry, I misspoke in my answer. I said “do it_” once when I meant >> “dispatch_” (probably because I was looking at the phrase while I was trying >> to type a different one). Hopefully that wasn’t too confusing. >> >> Just to be clear, leave “do it_” exactly as it is; it doesn’t need to >> change. Just add the abstract definition of “dispatch_” that I mentioned. > > got it. > thank you for teaching me! > > cheers, > Robbert. >
