google / google/reflectable.dart
Decide on treatment of noSuchMethod forwarders
- Dominant language
- Dart
- Stars
- 386
- Forks
- 67
- PR merge metrics
- No merged PRs in 30d
Description
Cf. https://github.com/dart-lang/sdk/issues/34111, reflectable now differs from 'dart:mirrors' in an area where no discrepancy was intended, so we probably want to update reflectable to use the same approach as 'dart:mirrors' currently does.
The topic is noSuchMethod forwarders (nSM forwarders), and the above-mentioned issue highlights the fact that the implicitly induced nSM forwarders can be made visible by queries like `classMirror.declarations` in the following example:
```dart
import "package:reflectable/reflectable.dart";
import "thisfile_test.reflectable.dart";
class Reflector extends Reflectable {
const Reflector(): super(
instanceInvokeCapability, declarationsCapability, metadataCapability);
}
const reflector = Reflector();
class Param {
const Param();
}
@reflector
abstract class A {
int sum(@Param() int a, @Param() int b);
}
@reflector
class B implements A {
dynamic noSuchMethod(Invocation invocation) {}
}
void main() {
initializeReflectable();
ClassMirror classMirror = reflector.reflectType(B);
MethodMirror methodMirror = classMirror.declarations['sum'];
print(methodMirror); // 'null'.
}
```
It prints 'null' because there is no method named 'sum' in the declarations from `B`.
In contrast, 'dart:mirrors' does include a method mirror for `#sum`, which means that the virtual machine _does_ give access to nSM forwarders, and that's a very meaningful approach given that we can also tear such methods off (so they definitely "exist" according to the semantics of the language).
This issue is aimed at getting this semantics implemented, such that nSM forwarders are revealed as if they had been regular declarations in the class where they are induced.
Contributor guide
Assessment
This issue has not been assessed yet.