-
Notifications
You must be signed in to change notification settings - Fork 32
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
Better mechanism for non-DSL calls using converters (or make converter_for do more) #18
Comments
ah, this looks like a missing enum conversion unless I am mis-reading this? |
converter_for just makes the methods for converting and the DSL mechanics end up using the converter method. So I think since this is a not a fcall we end up not calling the conversion logic. I am thinking about re-thinking how we specify converters and maybe making it a generic gem. One issue I realized is that arity is specified based on how we provide arg lists in Ruby versus arity of Java method signatures we want to map to. Converting a method which takes one int and then a varargs should be specifiable, but the syntax we are using cannot help us. |
Now that we have the declarative yaml file, i've been making it generate normal snake cased converters instead of DSL only converters and I think we should phase out dsl-only converters as that is a breach of expectation |
When I originally made them DSL-only it was with the idea that people may still want access to the actual method without our magic in the way. I can see your meeting expectations argument but I figured it was less of a reality issue since very few Rubyists use the snake-cased syntax. To play devil's advocate with my original change I will say that the converters do pass through correct values if they are already in the proper type. Or perhaps another way of stating that is if I pass in a Color instance our converters won't change it. Perhaps based on my last argument the only reason someone would want the original proxy method is to avoid performing a block dispatch. It would be for purely a fine-tuning if block dispatch overhead is killing their app. I don't know if that is a good enough scenario to not just go with what you suggest. Worst-case we can change generator to make aliases so we can still call the original method later if it becomes an issue. |
??????? me is confused??????
yea. I wasn't suggesting removing that.
cantTheyThenUseCamels? My suggestion is: clone master and run also, I drafted this up: https://github.com/jruby/jrubyfx/wiki/Developer-overview thoughts/suggestions? |
Sorry I meant CamelCased not snake_cased :) I was just playing devil's advocate in that second paragraph...not putting any words in your mouth. Actually I will come on irc since I think I totally missed what you want to do. I thought you wanted both snake and camel-cased methods to use converters. I definitely misread this but now I don't know what you mean... |
I just hacked this for drag_event.rb:
This snippet shows how I worked around being able to:
Notice since we are just calling a method on an object our DSL is not firing the converters on the arguments. I was going to just make another method for this but I am wondering whether converter_for should do this logic by default. What do we think?
The text was updated successfully, but these errors were encountered: