How to pass empty lists to invokeSetter without knowing the list type?

[alessandro-amos]

Hello.

I’m having trouble using invokeSetter with typed lists.

Consider the following code:

class Reflector extends Reflectable {
  const Reflector() : super(instanceInvokeCapability);
}

const reflector = Reflector();

@reflector
class Person {
  String? name;
  int? age;
  List<Address>? addresses;
}

@reflector
class Address {
  String street = '';
  String city = '';
}

void main() {
  initializeReflectable();

  Person p = Person();

  final im = reflector.reflect(p);
  im.invokeSetter('addresses', []);
}

The problem is that when I call im.invokeSetter('addresses', []), the value is interpreted as List<dynamic>, but the property actually expects a List<Address>.
If I pass an explicitly typed list (<Address>[]), it works. However, in my case I don’t know the Address type at compile time — it’s only discovered via reflection.

My question is:
Is there a way to:

1. Retrieve the expected type (List<Address>) from the mirror?
2. Create or cast an empty list to that expected type, without having to write <Address>[] explicitly?

In other words, I’d like to be able to instantiate the correct empty list with the reflected type, so that invokeSetter doesn’t throw a type error.

[eernstg]

Quick answer: const <Never>[] will do if it's OK that the list can't be modified by the callee. List<Never> is a subtype of List<T> for every type T, so this will be OK no matter which type argument is required.

In general, reflectable itself does not offer general support for extracting the value of an actual type argument as a type, and the reason for this is that there are no primitives in the language that allow us to do this. Reflectable is based on code generation, and this means that if you can't write the code to do something then there's no way a code generator could generate code to do this impossible thing.

You can use equality of types if you know that the type must belong to a finite and small set. In the example you should be able to use mirrors to obtain a Type for the declared type of addresses, and if you know that it must be List<Address> or Set<Address> (and it's guaranteed that no other type is possible in this situation) then you can test for that directly (theDeclaredType == List<Address> respectively theDeclaredType == Set<Address>), and then you can handle each case separately. This is not very maintainable, though, because it breaks as soon as there is a type that you haven't remembered to test for.

You can also do some things at the base language level (without using mirrors for this particular task).

For example, if addresses already has a value then you can create a fresh (and mutable) list with the same type: theList.take(0).toList(growable: true), and then populate the newly created list with whatever you need (or let the callee modify it as needed).

[alessandro-amos]

Ah, I see! I was looking at this feature request [#252] and it seems like this would solve my problem. Would it be very complex to implement something like this? Do you think I could do it "on my own"?

[eernstg]

The approach which is described in #252 will provide access to a type as a genuine Dart type (not as an instance of Type). Among other things, this means that it will be possible to compare it to other types (if you have Type t1, t2; then you can determine whether t1 == t2 which means, roughly, that they are the same type, but you can't check whether t1 is a subtype of t2, you can't check whether a given object o has type t1 or not, etc; but if you have access to two types because they are the value of two type variables X and Y then you can check whether one is a subtype of the other, and you can check o is X).

So this would definitely be a step forward for some applications.

However, it still doesn't support working with types that are the value of a type variable, because the generated code needs to work with ground types (in the example in #252 the types are A, _B, C, and D, and they all denote a specific class, not a type variable).

I think it would be useful for you to perform a couple of small experiments based on this idea, using hand-written code rather than generated code. Hopefully that'll reveal whether the generality of this idea is sufficient to support your use case.

[alessandro-amos]

So I tried a quick experiment by tweaking the generated code.
What I did was to add a generic type parameter to ClassMirror and update the generated code like this:

r.NonGenericClassMirrorImpl<prefix0.Address>(
        r'Address',
        r'.Address',
        134217735,
        0,
        const prefix0.Serializable(),
        const <int>[0, 1, 9],
        const <int>[10, 11, 12, 13, 14, 5, 6, 7, 8],
        const <int>[],
        -1,
        {},
        {},
        {
          r'': (bool b) =>
              () => b ? prefix0.Address() : null,
        },
        -1,
        -1,
        const <int>[-1],
        null,
        null,
      ),

In this case, I just added the type prefix0.Address to the instantiation of r.NonGenericClassMirrorImpl.

In the source code, the change was to introduce a generic type and a helper method in
NonGenericClassMirrorImpl, ClassMirrorBase, and ClassMirror:

class NonGenericClassMirrorImpl<T> extends ClassMirrorBase<T> {}

abstract class ClassMirrorBase<T> extends _DataCaching implements ClassMirror<T> {
  @override
  D callWithType<D>(D Function<T>() f) {
    return f<T>();
  }
}

abstract class ClassMirror<T> implements TypeMirror, ObjectMirror {
  D callWithType<D>(D Function<T>() f);
}

With that in place, I was able to obtain a List<Address> directly:

void main() {
  initializeReflectable();

  final Map<String, ClassMirror> classes = <String, ClassMirror>{};

  for (var classMirror in serializable.annotatedClasses) {
    classes[classMirror.qualifiedName] = classMirror;
  }

  final person = Person();
  final im = serializable.reflect(person);

  final addressList = classes['.Address']!.callWithType(<T>() => <T>[]);
  im.invokeSetter('addresses', addressList);
}

Does it make sense to adjust it this way?

[eernstg]

That certainly makes sense!