Proposal to update yokolets Poplar fraction as a gem example (jruby-extension)

[monkstone]

@enebo The coding work has been mainly done here and I would be completely happy losing ownership to jruby group, but it was @yokolet project originally I have an active PR to merge my branch with her original (but that may not suit and I would actually prefer jruby adoption). The advantage of jruby ownership would be that it would stand a chance of being updated as jruby evolves...

[headius]

@monkstone Great, thanks for the ping! I would definitely like to get this into JRuby's organization and make it part of our regular testing. I'm sure we can also improve and expand the set of features this code demonstrates, too.

@enebo what do you say?

[enebo]

@headius sure. sounds like a good idea.

[headius]

So would we want this as a standalone project? A new project under the JRuby org? Part of the jruby-examples project (which does have some ext examples right now)?

[yokolet]

Hi all, I'm ok with either. If necessary, I'll transfer the repo.

[monkstone]

@enebo @headius @kares Ahem this seems dormant. In the meantime wonder it there is any interest in these three blogposts:- http://monkstone.github.io/jruby_art/update/2016/04/20/hype_advanced.html http://monkstone.github.io/jruby_art/update/2016/04/25/hype_lambda_tween.html http://monkstone.github.io/nested_callbacks

[kares]

Hey Martin, I do like your posts (and the work you put into JRuby) - one thing a bit confusing on first sight is the Java cast being "converted" to Ruby :

    d = obj.to_java(Java::Hype::HDrawable)
    d.no_stroke.anchor(-20, -20)
    field.add_target(d)

... it's a matter of style I guess - any reason not to :

    obj.no_stroke.anchor(-20, -20)
    field.add_target(obj)

also as an advanced JI consumer your feedback on improving JRuby's Java support is welcome :)

[monkstone]

@kares Well that's the interesting bit the cast is definetly required, because for some reason Joshua Davis interface takes a java Object obj, and the addTarget requires an instance of HDrawable (which is an abstract class) and that would look untidy! In my opinion the design of Hype library leaves something to be desired.

[monkstone]

@enebo @kares I've been inspired to explore the JavaInterface.impl and posted examples here and it occurs to me that this might be a better way to implement the PBox2D ContactListener than my previous version (where I created a actual implementing class after including the Interface as a module), what do you think, plus would it be worth publicising as it doesn't seem to get much of mention.

[kares]

seems like impl is good example for org.jbox2d.callbacks.ContactListener but the "standard" include InterfaceModule way is as good as well if not more cleaner. for Comparator I would generally use the simple block-to-functional-iface conversion but it seems like you really need equals as well (which is unusual for the Comparator contract).

[enebo]

I still keep going back to this snippet in my mind :)

If the problem is that addTarget() has a ambiguous signature we cannot figure out then shouldn't you move that to_java as close the the problem method as possible? When I read it above it just looks like a mistake to me at a glance. In the snippet below, I will assume it is something odd about add_target:

 obj.no_stroke.anchor(-20, -20)
  field.add_target(obj.to_java(Java::Hype::HDrawable))

[monkstone]

@enebo turns out casting may not be needed after all, I must have done two changes at once or something, that convinced me it was required (under further investigation).

[enebo]

@monkstone yeah in general this casting will only be needed when there are two signatures which will accept the argument (or it is java.lang.Class). Which while not rare is pretty uncommon. So I think we all get fixated on to_java whenever we see it :)