Skip to content
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

macro for moving VNode construction overhead to compile-time #261

Open
cornerman opened this issue Nov 16, 2018 · 2 comments
Open

macro for moving VNode construction overhead to compile-time #261

cornerman opened this issue Nov 16, 2018 · 2 comments

Comments

@cornerman
Copy link
Member

No description provided.

@busti
Copy link
Collaborator

busti commented Nov 18, 2018

I have to admit that I am not very fond of the current state of macros.
Scala 3 is getting closer and closer, which also means that the end of macros as we currently know them does too.

I currently tend to avoid all libraries using Scala 2 macros, since I cannot be sure if some of the features from these libraries will be supported in the future.

Using Scalameta might be a better fit.

@cornerman
Copy link
Member Author

Agree, we have to be careful to not depend on a macro as an integral part of the library. But I still believe that it would be beneficial for the performance to construct parts of a VNode at compile-time. The main part is reading the list of VDomModifier grouping them by type or name and then creating maps and lists for properties, attributes, styles, hooks and children.

So, we would want a def macro that is inlined at the call-site. This is sadly not possible with scala-meta since they have pivoted to be more about tooling - they deprecated annotation macros, too (see: https://www.scala-lang.org/blog/2017/10/09/scalamacros.html).

In the end, I believe that we will have some kind of macro system in scala 3, because it is vital for many libraries we are using daily. But, of course, we do not know exactly, so a macro in outwatch should just be an addition that can be used but is not needed. It could probably even live in a separate subproject if we do not want the default apply method to do this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants