Unsupported operation: location

[h3x4d3c1m4l]

Hi! Very nice work on this library. Unfortunately it looks like it is not able to get the source code location of classes in the same library.

Example Reflector code:

class Reflector extends Reflectable {

  const Reflector() : super(typeCapability, typingCapability);

}

const reflector = Reflector();

@reflector
class Solver {
   ...
}

Code crashing with error Unsupported operation: location:

TypeMirror aMirror = reflector.reflectType(Solver);
var srcUri = aMirror.location.sourceUri;

As both Reflector and Solver class are in the same library, I would expect it to be able to get the source code location of the Solver class.

[eernstg]

Thanks for the kind words!

It is true that location was never implemented (nobody asked for it so far).

We could implement it (which would make the generated code somewhat bigger), or we could remove the location getter from the mirror types (to clearly indicate that it isn't supported).

Is there a good story about why the source code location of a declaration would be useful for a library / code generator that is intended to support reflection at run time?

[sigurdm]

We could implement it (which would make the generated code somewhat bigger), or we could remove the location getter from the mirror types (to clearly indicate that it isn't supported).

It would most likely still get tree-shaken away when not used - so maybe space is not a big concern here. (The problem is of course if there are dynamic invocation of a location getter somewhere...)

[eernstg]

That's an interesting trade-off!

We would presumably have a locationCapability, and it might be applied to some declarations and not to others (e.g., we might want to know the location of all classes that we have mirrors for, but not every one of their members).

This probably means that DeclarationMirrorImpl would have an instance variable, perhaps final SourceLocation? _location, and that instance variable would be non-null for every (declaration) mirror with a location.

That might not be a problem (one more instance variable per mirror might just be a few percent), but it is the kind of cost which is paid by everybody, rather than a 'pay as you go' cost.

If we have a suitable notion of equality we could also use a global Map<DeclarationMirrorImpl, SourceLocation>, which wouldn't make every single declaration mirror bigger.

[h3x4d3c1m4l]

Is there a good story about why the source code location of a declaration would be useful for a library / code generator that is intended to support reflection at run time?

So I have this personal project I would like to use for demo and experimental purposes (link). At the moment it just contains my Advent of Code solutions, for which I'd like every solver view to be able to show and link (to GitHub) it's source code. To achieve that:

• Every solver class has a property with the path to the source code file (example).
• All relevant source files are included as asset as well (using pubspec.yaml)

It works well for now, but once I would move files, this could easily break. Being able to find the correct path in a dynamic way would be a very clean solution.