-
Notifications
You must be signed in to change notification settings - Fork 203
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Would it be possible to generate and combine code from different macros invocations in one place? #3854
Comments
There isn't a way to implicitly search all transitive libraries and generate code based on what you see. This is generally just a bad thing to do for performance reasons. It means that a single macro will have O(n) time complexity where n is the total number of libraries in the application, and there would be a large constant multiplier to boot. Worse than just the time to execute the macro, it will also have to re-run whenever any library changes, because it has an implicit dependency on every library in the program. We could try to design an alternative way to do this, which is more "modular", but it is challenging to design the semantics of it, and we aren't looking into it in earnest at this time. Essentially though, you would want the For this to be supported today though, you need some explicit piece of code referencing all the relevant types, to help you generate the @GenerateRoutes([HomeScreen, LoginScreen])
class AppRoutes {} |
I am going to close this as not planned for now, as we don't currently have any concrete plan to support it. |
As far as I understand, we don't need to depend on all libraries. All we need here is to have some kind of API method that could return all classes with metadata (in this case, Route). And then it seems it would be possible to generate the method.
I thought about code like this. If there is no other way, even this code would be OK. But in case of many screen classes it's still not that the best option from user point of view. Macros should help us to get rid of boilerplate, but the code like this is exactly with what macros should've help. |
The problem is that API has to visit all libraries to give you an answer. It has to look at every class in every library, and check for matching metadata. A naive implementation ends up re-running the entire query across the entire program, any time any change to any library is made. Yes, this could be specialized in some way, such that when a single library changed we know all the whole-app queries which were asked, run those queries only on that library, and compare the old results against the new results, and only re-run the macros whose queries were affected. But, this would be a lot of work to design and implement in any sort of general purpose manner, not to mention extra memory to hold onto these query results indefinitely, etc. It has to be very carefully thought out to work well. |
I've played a bit with the upcoming macros feature and tried to implement some kind of router generator. Here is the code. And I didn't find a way to generate an entry point to collect all route builders in one place. Basically, if we have:
I want to generate something like this:
Would it be possible to implement the macro to generate code like this? Or not? Or maybe it's already possible to do something like this? If so, how? Assuming it would be possible, what the approach would look like?
The text was updated successfully, but these errors were encountered: