Allow using dart:mirrors

[stevenroose]

I know that mirrors is blocked now because it causes the generated packages to be very large.

However, on the long term, it should remain a goal to find a solution for this. Many libraries use mirrors so not being able to use mirrors for Flutter apps will make the framework a lot less powerful.

The trade-off between large package sizes and using mirrors should be left to the user. A possible solution might be to use an explicit --allow-mirrors flag. But of course the ultimate solution should be to find a way to use mirrors without blowing up package sizes.

Java has reflection and Objective-C has Runtime Reference, so why would Flutter not have a reflection system?

[Hixie]

Allowing mirrors would mean we couldn't remove unused code (since all the code is implicitly used). That's what causes the code size increase.

Java apps are huge, that's one of the things we want to avoid. Objective C, as I understand it, doesn't trim unused members from classes either. It also doesn't strip any classes that are exported, because it uses dynamic linking.

Dart uses static linking (effectively), and using static analysis we can strip out anything that isn't used ("tree shaking"). If you import a huge Dart library but only use a self-contained two-line method, then you only pay the cost of the two-line method, even if that Dart library itself imports dozens and dozens of other libraries.

(At least, in theory. I'm not sure how much of this we implement yet.)

We could enable mirrors only for classes that you opt into (similar to Delphi's $M+). That would require support from the language.

[stevenroose]

@Hixie Isn't that what the @MirrorsUsed annotation is for? I thing dart2js also does tree shaking using the @MirrorsUsed annotation.

[Hixie]

I think that's more about avoiding name mangling, which is a whole other kettle of fish (we don't do any name mangling). But it would be a similar kind of thing, yes. To my knowledge the snapshotter doesn't support any annotation of that kind currently.

[stevenroose]

I quote from this article from @sethladd

Mirrors are really powerful, but they introduce challenges to dart2js's tree shaking abilities. Normally, dart2js can look at the entire app and deduce what code is required to run the app. However, as of the time of this writing, mirrors (due to their API design and highly dynamic nature) more-or-less disable dart2js's tree shaking.

Enter @MirrorsUsed, a metadata annotation, which explicitly states what parts of the program are reflected. Tools like dart2js can use @MirrorsUsed to re-enable tree shaking.

I think that the guys that wrote tree shaking for dart2js can really help you out here since it seems they had the same problem and managed to fix it. Of course, package size will still be larger when using mirrors, but the difference won't be as significant when tree shaking is done fairly efficiently.

[Hixie]

Ah, yeah, I didn't see 'targets' and 'metaTargets' before. Those could be used to do this, if the snapshotter supported them.

[sethladd]

MirrorsUsed is not supported and has edge cases it doesn't cover. I wouldn't build a solution around it.

[stevenroose]

@sethladd I noticed it said "experimental", yes.
But is it still the only thing that helps dart2js tree shaking with mirrors? Or are there other strategies.

Anyways, dart2js and Flutter seem to have a similar issue when it comes to mirrors usage, so I guess they can use the same "solution", however complete that solution might be.

I believe dart2js still warns users of large output size when it sees mirrors usage, that is a good practice. Better than preventing users from using it...

[floitschG]

There is also a reflectable package. It can either run untransformed, using
dart:mirrors, or transformed, where it extracts the information beforehand.
It is not complete, though. For example there is no way to access private
identifiers.
It also adds an additional build step...
On Jan 8, 2016 23:49, "Steven Roose" notifications@github.com wrote:

@sethladd https://github.com/sethladd I noticed it said "experimental",
yes.
But is it still the only thing that helps dart2js tree shaking with
mirrors? Or are there other strategies.

Anyways, dart2js and Flutter seem to have a similar issue when it comes to
mirrors usage, so I guess they can use the same "solution", however
complete that solution might be.

I believe dart2js still warns users of large output size when it sees
mirrors usage, that is a good practice. Better than preventing users from
using it...

—
Reply to this email directly or view it on GitHub
#1150 (comment).

[eernstg]

For completeness of reflectable, please check out the 'Known limitations' section at the end of https://github.com/dart-lang/reflectable/tree/master/reflectable.