-
-
Notifications
You must be signed in to change notification settings - Fork 656
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
Expression macro method forwarding #7453
Comments
I just reread the proposal and got a slightly different idea for implementation that requires less metadata. Since we have support for //Main.hx
class Main {
static function main() {
js.Browser.console.log("Version " + getVersion());
}
static macro function getVersion();
}
//Main.macro.hx
class Main {
static function getVersion()
return macro $v{haxe.Json.parse(sys.io.File.getContent('haxelib.json')).version};//or whatever
} This would achieve a clean separation, be consistent with an existing convention and avoid having the user come up with additional names as |
I remember having some idea with I guess these ideas complement each other and could work together quite well... |
Can you elaborate on how you would use them together? |
I mean, they are not really related, you just reminded me about it :) I thought that having macro code in I also like your idea, it looks pretty convenient, thought I'm a little concerned that one might end up with redundant modules if they want to forward to the same macro function implementation from different places. |
I'm now wondering, maybe that already just works through the |
using |
I also wonder what happens with On another note, maybe our planned auto-using feature could solve this as a subset. |
Dan:
Heinz:
Me:
That's a genuine question. How often do you use the same implementation for two different macros. I do quite often have common logic that is extracted to standalone classes, sure. But the same macro twice? On a sufficiently regular basis to warrant for a syntax that's honestly not all that self-explanatory? You'll forgive my skepticism, but the evolution proposal doesn't even mention this use case. For me the root problem motivating the proposal is the problematic bleeding together of the macro and target context. It's a recurring problem that can scare away newbies way more than it has to (and is still rather annoying to experienced macro users). If we would simply tell them that they should put the implementation of their macros in a It's not like the features are mutually exclusive. But if the
Yup, I've checked it works with
|
Well ok, in my special case i have a macro that merges static APIs, it also has to do with the limited abilities of the module/import system. It works very good for static methods, but for macros i have to add them piece by piece to the api. The following example should make that clear (Source and Source 2). The idea is that you can build your api in a modular way, but have the possibility to merge them together for ease of use. |
but yes, for other cases .macro.hx could work fine and i also like it. |
I looked a bit into implementing that and the thing described by @back2dos is just working accidentally already. The only minor issue there is that the signature of the So, now I wonder whether we really want |
I still think that metadata is a much more flexible and more generic solution. It's also something that can be generated when building a class inside of a macro etc. There is currently no way to add macros to those classes, but with meta data this may be possible. |
Okay, let's have both, but after 4.0 I guess. I'll add a test for Juraj's example though :) |
@nadako does this proposal still make enough sense nowadays? With |
I'm making the decision that we don't need this. There were doubts before, and by now we have enough tools to deal with this situation. There are also some other problems which the original proposal doesn't address, like how call arguments are to be unified between the two functions. Not closing yet to make sure we update the haxe-evolution accordingly. |
Yeah I think |
HaxeFoundation/haxe-evolution#18
The text was updated successfully, but these errors were encountered: