Generate Object getter/property macros to remove duplications#15386
Conversation
Generates the macros from an external script that will inline the actual macro implementations, instead of using macros to generate the macros and duplicating the actual implementation multiple times.
…l-lang#15386) Generates the macros from an external script that will inline the actual macro implementations, instead of using macros to generate the macros and duplicating the actual implementation multiple times.
ysbaddaden
force-pushed
the
refactor/object-property-macros-generator
branch
from
60ef33a to
b3237ec
Compare
|
Working on the follow ups: the docs and adding crystal once to protect class getter/property, I realize there is little point for most of the I'm having second thoughts about splitting the docs PR. Both PR are two sides of the same coin: remove the duplication, be it in the documentation of the implementation. Modifying one irremediably ripples to the other. |
|
What I mean with two sides of the same coin: here I merely moved the documentation and it makes sense to introduce the But as I start writing distinct docs for each macro to outline their distinct behavior, then the But if we try to first change the docs, then we must extract each individual macro, further duplicating the implementations Said differently: 🐔 <=> 🥚 problem. |
…l-lang#15386) Generates the macros from an external script that will inline the actual macro implementations, instead of using macros to generate the macros and duplicating the actual implementation multiple times.
…l-lang#15386) Generates the macros from an external script that will inline the actual macro implementations, instead of using macros to generate the macros and duplicating the actual implementation multiple times.
There was a problem hiding this comment.
I think the value in having this change standalone is that it only restructures the implementation. It does not affect the final result. The generated docs from this branch has only insignificant differences to master.
That's awesome as it means the change is entirely internal. But it sets us up for the next step.
When we reorganize the actual documentation, we can also refactor the generator script to simplify it for the new requirements. But that will only be chaning an implementation detail of the generator file.
The structural changes of moving stuff around in the repository and setting up a code generator will already be prepared at that point.
2 participants
Alternative to #15383 that inlines the macros' implementation instead of calling to external macros, but without any impact on compilation times or memory usage.
Like #15383 it avoids the repetition of the implementations across the set of
class_(getter|property)[?]macros. Since we don't have "macro functions" in Crystal, the "inlining" needs an external crystal script to generate a static file with all the macros.In #15428 I started refactoring the docs, which led to simplify the generator presented here.
Implementing #14905 will only require to specialize the
Generator#def_gettermethod for the class variant, then run the script to regenerate all the macros. See #15387 for more details.