On May 10, 2018, at 11:53 AM, John Rose <john.r.r...@oracle.com> wrote: > > The easiest thing is to assign *one* calling sequence per v-table > slot, based on the preferences of the first class allocating the slot. >
P.S. I suppose that key point was too telegraphic. Trying again: The easiest thing is to recognize that we can (and do, already) assign *one* v-table slot and highest super-class to each concrete method defined in a class. (Default methods don't get to do this, though.) If the method is not an override (according to descriptor match, not JLS rules), then that class is the super and the v-table slot is fresh. If the method is an override, then it inherits its v-table slot from the method it is overriding. Given that assignment, we can assign a unique calling sequence per v-table slot, and (equivalently) to the tree of overrides in that slat. Base this on the preferences of the highest class (common super). All concrete methods sharing that same v-table slot must interoperate with the same view of types. The CLCs dictate the same thing, already. The CLC mechanism may be extended (if we choose) to spread the unique calling sequence constraint through default methods. This would enforce a unique view of val vs. ref across all v-table slots, for each concrete method, even defaults. The above logic works even if your JVM impl. doesn't use v-tables. The rules simple decorate methods according to the preferences of the highest classes in in each override tree. Can the "highest class" define its method as abstract, not-concrete? Sure; then you have an override forest, not an override tree. So you assign the same calling sequence to the whole forest. And the information is rooted in the abstract method. That's why I started out by saying the information flows from a v-table slot. But it flows through concrete overrides, as well as (optionally) the top method that they all override.