Subtyping by augmentation is too ad-hoc

[Kaiepi]

Consider:

use MONKEY-TYPING;

class Foo { }

class Bar is Foo { }

role Baz { }

augment class Foo does Baz { }

Given a Bar inheriting from Foo, which does Baz after the fact, the following should become True:

Bar ~~ Baz

This is False because Metamodel::MROBasedTypechecking.publish_type_cache on Bar steals Foo's role typecheck list for its typecheck cache as it stands at that point in time. This untimely reference also leads to a need to recompose type objects in the setting because there isn't guaranteed to be a complete role typecheck list when this metamethod wants there to be one in general.

It should be possible:

• To update typecheck caches gradually to allow HOWs to more readily take advantage of them.
• To allow a type to subsume another type such that a cached typecheck checks the sum of the type's own cache and those of its subsumed types.

[vrurg]

Augmentation was already discussed a while ago, though I can't neither recall nor find the exact issue where it took place. But the conclusion I carried out of it is that the only clean solution to the problem is keeping record of class' subclasses.

Unfortunately, the approach has some harmful drawbacks. I could start with a note that children registry is a sparsely used information, sometimes it would occupy memory and yet never be actually needed. Perhaps the most effective implementation would be done on VM side. It could have a table of pointers to children's HOW instances and invoke a callback method on them. It's cheap from memory consumption perspective. And it is sufficiently clean as it allows the children to decide what actions to be taken if a parent has changed. Updating their type check caches could be one of those.

The weak points of the approach:

• it would require support from all backends
• it may results in additional complexity added to already pretty much convoluted serialization
• it is likely to make augmentation very costly operation as it is likely to result in an avalanche of callbacks; minor as it's not something done frequently
• there is a likelihood of changes done to the parent which would require full re-composition of a child. But some parameters of class' HOW are not-recomposed on second .^compose.

The last item is perhaps the most worrisome as sometimes it might mean that a child class must be re-created from scratch. But may have its own descendants...

This is just what surfaces in my mind immediately when I think about augmentation. There're perhaps more issues lurking out there of which I'm not aware yet.

[niner]

If parent classes know the subclasses, this also means that we can only every garbage collect those subtypes, when the parent and all its children become unused. E.g. a subtype of Int would never be collected.

[moon-chilled]

No weak references?