Better mechanism for non-DSL calls using converters (or make converter_for do more) about jrubyfx HOT 6 OPEN

ah, this looks like a missing enum conversion unless I am mis-reading this?
wait, why is it not firing the converters? converter_for should have this in it

from jrubyfx.

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.

from jrubyfx.

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

from jrubyfx.

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.

from jrubyfx.

very few Rubyists use the snake-cased syntax.

??????? me is confused??????

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.

yea. I wasn't suggesting removing that.

Perhaps based on my last argument the only reason someone would want the original proxy method is to avoid performing a block dispatch.

cantTheyThenUseCamels?

My suggestion is:
move remaining converters to yml file if possible
converters expand to override the ruby-like snake cased methods
use same converter logic as before where we only convert stuff that is needing converting

clone master and run rake reflect and then stare at jrubyfx/core_ext/precompiled.rb and the second half of jrubyfx/dsl.rb

also, I drafted this up: https://github.com/jruby/jrubyfx/wiki/Developer-overview thoughts/suggestions?

from jrubyfx.

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...

from jrubyfx.