We should consider adding a method isSubtypeOf in class Type to check if a type instance is a sub type of another instance

[a-siva]

The widget code in Sky uses mirrors in the following scenario to query if the type of an object is a subtype of another target type.

Widget findAncestor(Type targetType) {
var ancestor = _parent;
while (ancestor != null && !reflectClass(ancestor.runtimeType).isSubtypeOf(reflectClass(targetType)))
ancestor = ancestor._parent;
return ancestor;
}

We would like to eliminate all uses of mirrors in Sky code as we will have issues with it when precompiling and tree shaking for the ios platform

@sgmitrovic @crelier

[crelier]

We could provide this functionality in the class Type of the SDK. Instead of

abstract class Type {}

we could have

abstract class Type {
bool equals(Type other);
bool isSubtypeOf(Type other);
bool isMoreSpecificThan(Type other);
Type superType();
}

Other methods to inspect function types may be useful too:
bool isFunctionType();
int FunctionTypeParameterCount();
Type FunctionTypeParameterTypeAt(int i);
Type FunctionTypeResultType();

static Type VoidType();
static Type DynamicType();
static Type NullType();

To be complete, we would also need access to optional arguments, since they are considered in function type tests:
int FunctionTypeFixedParameterCount();
int FunctionTypeOptionalPositionalParameterCount();
int FunctionTypeOptionalNamedParameterCount();
String FunctionTypeParameterNameAt(int i);

All the above is already implemented in C++ in the VM and would just have to be exposed on the Dart side. This is an API change, obviously.

[lrhn]

I'm sympathetic to adding more functionality on Type (so it has a reason to exist except as an opaque token tightly coupled with the mirror system), but it's not uncontroversial.

Personally I'd want at least:

  class Type<T> {
    bool isInstance(object) => object is T;
    bool isSubtypeOf(Type other) => ...;
 }

I don't think the function inspection is a good idea - that's too close to reflection, and then you can just use mirrors.

In general, passing around Type objects is not a good idea (right now). They are pretty much useless without the mirror system, so it would be better to have some other representation of your widgets than a Type object. For the findAncestor function I would probably go for: findAncestor(bool test(Widget widget)) instead of passing in a Type object. That's far more general. Then the user can do: findAncestor((x) => x is FooWidget) instead of findAncestor(FooWidget), getting the full subtype-test support of "is" without having to implement it manually. If we get generic methods, it can even be: findAncestor<T extends Widget>([bool test(T widget)]) which checks parents with is T and can then also use the optional extra test.

In short: If you use Type objects for anything else than putting them into the mirror syustem, it'll most likely suck, so don't do that.

Adding anything to Type will conflict with the metaclass proposal which wants to treat static members of a class as instance members a corresponding Type object - that would be complicated if some names were shadowed by the Type class itself.

[a-siva]

I don't think we should speculatively add functionality without first having a use case for it. I think a good first step would be to find all the 'dart:mirrors' usage in the Sky framework and get that functionality in through other means.

Regarding passing Type objects around, we can only suggest as a recommended patterns but it is always up to the user as to how they use it.

[sethladd]

@larsbak had a suggestion for the Sky code in this particular case, in order to eliminate the need for mirrors here.

[mraleph]

I think this issue is stale - and it is not a VM issue but a language/core library one