lrhn
commented
3 weeks ago Automatically generating code is what macros is intended to answer.
A toJson macro is the first macro being built for the the feature, so it should be able to support that.
Dart is not JavaScript, not everything can be converted to JSON, or a map. In some cases, choosing a good representation is non-trivial, and a naive conversion could be disasterous for performance. One size will not fit all. Building one design into the compiler risks that design not being what people want, and what people want may change over time. A feature needs to be either so complete and configurable that you can use it for everything, or it needs to be optional, so it doesn't matter if it becomes obsolete.
The Dart mirrors core library (
dart:mirrors) is currently in a sub-optimal state:It is marked "experimental" in the list of core libraries
It is marked "unstable" in the API docs
It is unsupported in the Dart web platform
Is is disabled from use in the Flutter framework (and has been so for years)
We've investigated potentially making mirrors a stable, fully supported offering, however in its current form this has a few large challenges:
Dart has powerful "tree shaking" for ensuring we can produce apps with small code sizes. This relies on the ability to detect unused code, which doesn't work if reflection can use any of it dynamically (it essentially makes all code implicitly used).
The APIs supported by mirrors are significantly behind the current Dart language, for example they do not support extension methods or null safety.
We believe that one of the core uses of mirrors is to do various forms of code generation and meta-programming. Before we potentially fully discontinue mirrors, we'd like to better understand the desired use cases here so that we could have alternative solutions and migration path ready for current users before we make any changes to
dart:mirrors. If you have any such use cases, please leave a comment.