"Attempt to get isSubtypeOf without typeRelationsCapability" while typeRelationsCapability is present

[stevenroose]

This are the capabilities I have in my reflector:

      declarationsCapability,
      newInstanceCapability,
      staticInvokeCapability,
      subtypeQuantifyCapability,
      typeRelationsCapability

However, at some point during testing in transformed mode, I get this error: Attempt to get isSubtypeOf without typeRelationsCapability. (full stack trace)

Just to be sure: the typeRelationsCapability also counts for the classed indirectly reflected by the subtypeQuantifyCapability capability, right?

This is the branch where I get the error (using pub test -p firefox): https://github.com/stevenroose/pointycastle/tree/web-test

[eernstg]

Indeed, the typeRelationsCapability is available for all supported classes here, in particular all those classes which have been included because of a subtypeQuantifyCapability.

But I suspect that the isSubtypeOf method reports an incorrect error: In the given situation it is known that the superclass is not available (because its index in a certain data structure is the special "We have no such thing" value), but this could also be the case because that superclass is not supported at all, and then it does not help that there is a typeRelationsCapability. In order to give a more precise error message we will probably have to traverse the capabilities in the reflector and check whether there is anyone of type TypeRelationsCapability, and report a "un-marked class" error if it is present.

So I'd expect that you need to check the set of covered classes and ensure that it is sufficiently large.

I'll look into the error message improvement later.

[stevenroose]

There is a fundamental flaw here. Consider this:

@MyReflector()
class A {}

class B extends A {}

class C extends B implements SomeInterface {}

@MyReflector()
class D implements SomeInterface {}

class MyReflector extends Reflectable {
  const MyReflector() : super(subtypeQuantifyCapability, typeRelationsCapability);
}

The subtypeQuantifyCapability makes sure that all of A, B, C and D are in the reflected set.

When calling classMirrorOnC.isSubtypeOf(classMirrorOnA), how does the algorithm traverse the tree? Since SomeInterface is not reflected on, if the algorithm first tries going up the tree via SomeInterface, it will throw.

The same happens with classMirrorOnD.isSubtypeOf(classMirrorOnA). This should return false, but will throw because SomeInterface is not reflected on.

So basically, all classes implementing interfaces or extending classes that are external to the reflected set (which is very very common!), won't be able to use the isSubtypeOf method.

For my specific implementation, I am thinking about no longer using inheritance to find classes I need, but check for the presence of a static variable (I'm lucky that all classes I need to find do have a static member in common). But this problem stays a fundamental one IMO.

[eernstg]

So you're saying that you cannot specify the complete set of classes needed for the normal subtype check (e.g., because it pulls in a very large number of classes, or you are working on a library where this set of classes is determined by clients and hence unknown in the library)?

It is not obvious to me that it would be a useful semantics to, say, ignore part of the type graph and return wrong results in some cases; returning false could then mean "the argument is not a supertype" and it could just as well mean "the argument is a supertype, but we don't have enough information to detect that". It also seems convoluted to have programmers define ad-hoc exceptions like "when computing isSubtypeOf, ignore the following classes: SomeInterface, ...". In other words, the obvious alternatives to saying "we couldn't do that" look rather messy.

One possible way out: If you only use inheritance then you should be able to use isSubclassOf rather than isSubtypeOf.

[stevenroose]

Yeah I agree with that only a partial check is not a solution.

It's just a problem. There are a lot of classes that just implement interfaces like Map or List.

In fact, using isSubtypeOf needs both the subtype and supertype capabilities so that reflectable will include the whole inheritance graph. This will of course impose all other capabilities to all these classes too.

What would sound more logical to me would be to let typeRelationsCapability include this whole graph, but only the isSubtypeOf functionality. So even without subtype and supertype capabilities, reflectable would make the complete inheritence graph around all reflected classes, but not impose all other reflection capabilities on all classes in this graph. Just their type relations.

[eernstg]

CL https://codereview.chromium.org/1695453002/ changes the error message for isSubtypeOf and isAssignableTo such that they do not mention the type relations capability (which was only correct in some cases, not including the one that you encountered). That CL also makes superinterfaces require the type relations capability in transformed code (it used to incorrectly omit that check). The new issue #76 deals with the deeper underlying problem that isSubtypeOf and isAssignableTo are so expensive, spacewise (but there is no obvious solution to that problem at this point).