<byteit101[m]>
two things: I should have some time starting wednesday to write some stuff up as per your request two weeks ago, headius. What is the intended audience, platform, etc that you were hoping for?
<byteit101[m]>
and second: any further thoughts on the api naming?
<headius>
Oh shoot yeah, I have been all over the place. Tomorrow perhaps we can finalize this with enebo
<byteit101[m]>
Tomorrow I'm very busy but read my comments, ponder, and respond, and I will hopefully read your thoughts in the evening
<headius>
Ok no problem
dangerousdave has joined #jruby
dangerousdave has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dangerousdave has joined #jruby
sagax has joined #jruby
dangerousdave has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dangerousdave has joined #jruby
dangerousdave has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<headius>
enebo: You have any more thoughts on the naming for byteit101 instance variable Java field feature?
<enebo[m]>
oh let me review his latest comment
<enebo[m]>
heh...I am not sure what is the actual proposal at this point
<enebo[m]>
I see you say instance_variable but then you use java_field
<headius>
java_field is the existing method we are adding this to
<enebo[m]>
So we declare java_field and this other method name is how we access it from ruby as an instance variable?
<enebo[m]>
ok I reread this
<enebo[m]>
instance_variable: true to me makes it clear the field is going to become accessible via @ivar
<enebo[m]>
It literally says this field is also an instance_variable
<enebo[m]>
So I do not find the verb will help and it will definitely not be easier to remember that + verb
<enebo[m]>
as for 'convert' I am not sure I like that or 'to_java'/'to_ruby'
<enebo[m]>
well I like convert more than any other word
<enebo[m]>
I do have a question...the field itself declares a type
<enebo[m]>
if nothing is provided I assume it "converts" to the declared field type?
<enebo[m]>
unless it is false or false is the default but it needs to really be that type then
<enebo[m]>
In this case I have to basically @address = {an actual Java instance of j.l.String}
<headius>
right so that would produce wrapped Java String objects rather than converting to RubyString
<enebo[m]>
if convert is true (let's pretend there is a true value) then it knows it should be j.l.String so it shoudl try to convert to that automatically
<enebo[m]>
So a specific convert: some.Type is for which case?
<headius>
hmm what'
<headius>
what's a good example
<headius>
maybe numerics
<enebo[m]>
Maybe a base type in Swing?
<enebo[m]>
JComponent is field type but we want to force it to a narrower type?
<enebo[m]>
headius: but if it is a subtype stored as a less specific type I am not sure it does anything unless our convert itself has special logic
<headius>
so any assigns to that field would be asked to convert to a Double
<enebo[m]>
ok so Numeric could be Integer or Double
<headius>
there may be a better example as part of jrubyfx
<enebo[m]>
but I assume convertign RubyFloat to numeric will just do the right thing there won't it?
<enebo[m]>
yeah I am curious to see a concrete example here. I believe there may be one but right now true/false with one being the default feels ok
<headius>
lopex: hmm yeah that could be useful... cc kares
<headius>
the ssl thing
<lopex[m]>
pems, pfx, p12 all supported
<headius>
jdeploy would be worth playing around with to see if we can produce a smaller faster-starting JRuby bundle
<enebo[m]>
headius: our rubyToJava logic is unwrapping but it may also be creating something new. So convert is ok. I was thinking about coerce or cast. cast is not good
<enebo[m]>
My only other pondering is this actually something which is bi-directional?
<headius>
your point about the verb is a good one... the entire call is a declaration of some binding already
<enebo[m]>
In java you need it to at least conform to the field type
<headius>
bind this java field, with these extra characteristics
<enebo[m]>
so ruby->java could be no coercion because you know it is really a java instance being pushed to the ivar
<enebo[m]>
but there may be a need to do more which is outstanding question
<enebo[m]>
but if you do want RubyString -> Java String and the Java String -> Ruby String cool...it is bi-directional
<enebo[m]>
It maybe is too complicated to specify more bindings
<enebo[m]>
Spamming to myself. Our existing JI allows us to access the field and it will java2ruby and ruby2java that route
<enebo[m]>
That technically means convert: true could be eliminated but that would be bad ergonomics since @address is just a nicer syntax
<enebo[m]>
convert is an action/verb
<enebo[m]>
headius: I added a comment and I think Patrick said he is very busy today so I will not ping his handle :)
<headius>
ok
<enebo[m]>
The specific convert bugs me...since I cannot visualize why if it is accessed from an ivar you need a specific type but at the class level you need a more general type
<enebo[m]>
All I can think of is there is another path into that field where java will set the more generic type
<enebo[m]>
but then if it is not the more specific type you will crash trying to access it from the ivar
<headius>
yeah maybe that could use some clarification
<enebo[m]>
and I am not saying it isn't needed I just cannot see how the mismatch works
<headius>
we do have a few types that can be expressed in a number of ways like Time, but it's not clear to me why the actual Java field type would be the wrong target
<headius>
Time can convert to a Java Time, Date, Joda DateTime, etc
<enebo[m]>
yeah if you have one Ruby type which can be 3 Java types this would allow you to specify but then why not make the field that
<headius>
but you wouldn't expect a target field to have a generic supertype of those
<enebo[m]>
yeah that's also true
<enebo[m]>
ok well it sounds like we both want to see this example then
<enebo[m]>
I am guessing convert: true is the default
<headius>
yeah should be
<enebo[m]>
seems like most people would expect java2ruby
<enebo[m]>
ok
<enebo[m]>
So I am on board with the name choices you came up with and I think we just need to get more info about whether convert needs more than true/false
<headius>
Ok
<headius>
So back to the define method rewriting for a sec
<headius>
I was looking through the logic you have and it doesn't clone the IR, it actually recompiles it from the original AST
<headius>
There's logic to check that the AST is still available, which would be a bit of a concern for me because I need to be able to do this super target rewriting in all cases
<headius>
Would cloneForInlining be appropriate for cloning the whole IR scope?
<enebo[m]>
cloneForInlining does a lot more than just clone
<enebo[m]>
err wait let me look at something
<enebo[m]>
headius: cloneForInlining will work for closures but you need to pass SimpleInlineInfo
<enebo[m]>
Err SimpleCloneInfo()
<headius>
Yeah I don't need to change anything for inlining so I just really want a copy
<enebo[m]>
The entry is a little weird but I think closure.cloneForInlining(SimpleCloneInfo(closyure)) should do it
dangerousdave has joined #jruby
<byteit101[m]>
enebo: won't have time to fully respond for another few hours, but quick points: "unless our convert itself has special logic" <- that is one place I wasn't sure, and the other reason for specifying the class that I know of is numerics. 2) " it will definitely not be easier to remember that + verb" That's the point, see one of my earlier comments in the PR on why that was one of my goals. I'm curious if you disagree with the reasoning
<enebo[m]>
byteit101: I did read it which was why I mentioned verb being more difficult to remember
<enebo[m]>
but think about a specific convert using numeric because I am not sure I understand how that would work in practice
<enebo[m]>
we can talk about both of those more when you have the time
siasmj has quit [*.net *.split]
siasmj has joined #jruby
dangerousdave has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]