JRuby

Allow visible fields from inherited Java classes show up as instance variables (@foo)

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: JRuby 1.1b1
  • Fix Version/s: None
  • Component/s: Java Integration
  • Labels:
    None
  • Number of attachments :
    0

Description

If I have a Java class:

public class Foo {
   protected int color;
   ...
}

Then I inherit from it in Ruby:

class Bar < Foo
   def paintIt
      @color
   end
end

@color should exist which is the inehrited field.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Charles Oliver Nutter added a comment -

Do we expose these now as attrs? Exposing as an instance var could be very tricky, since it would require hooking into (and potentially slowing down) hash-based lookup of non-field ivars.

Show
Charles Oliver Nutter added a comment - Do we expose these now as attrs? Exposing as an instance var could be very tricky, since it would require hooking into (and potentially slowing down) hash-based lookup of non-field ivars.
Hide
Permalink
Thomas E Enebo added a comment -

Can't we make a reference type which we can then store in a hash? Then when we create the JI class we add one shadow/reference type per field. The cost of access would be slower for those, but I do not think it would affect anything else? To say it yet another way...the same way we hook up global vars.

Show
Thomas E Enebo added a comment - Can't we make a reference type which we can then store in a hash? Then when we create the JI class we add one shadow/reference type per field. The cost of access would be slower for those, but I do not think it would affect anything else? To say it yet another way...the same way we hook up global vars.
Hide
Permalink
Bill Dortch added a comment -

I've been thinking about adding a reference type for a while now, though not in the 1.1 time-frame. My use case has been providing support for data binding and other such goodies – not directly in JRuby, probably as a gem, but with the underlying support/framework provided by JRuby. I've also been thinking about (possibly as an alternative) providing an event listener mechanism, so that code could register/listen for property events, including (but not necessarily limited to) ivar/cvar/constant events.

There will be some performance considerations with either of these approaches, but I think the impact can be minimized if done correctly.

BTW, I've also been thinking about using a reference type as part of an alternative method caching strategy, but I haven't had time to fully work this out. (Basically, a CacheSite [such as InlineCachingCallSite] would obtain a MethodReference, which would remain valid for all time [though the (volatile) referenced method might change]. The MethodReferences would be cached at the metaclasses where the methods were referenced. An event listener mechanism would be used to keep them up to date. As I said, not fully worked out.)

In general, I think we should consider building an event mechanism into JRuby 2 that will support listening for a number of internal event types. We should also consider exposing this mechanism through Ruby, via a gem or other optional module. Among other things, we could provide a superior (but non-standard and therefore necessarily optional) alternative to the rename-override-call_renamed approach of hooking events like :method_added.

Some internal code could also be refactored to use the new event mechanism.

Show
Bill Dortch added a comment - I've been thinking about adding a reference type for a while now, though not in the 1.1 time-frame. My use case has been providing support for data binding and other such goodies – not directly in JRuby, probably as a gem, but with the underlying support/framework provided by JRuby. I've also been thinking about (possibly as an alternative) providing an event listener mechanism, so that code could register/listen for property events, including (but not necessarily limited to) ivar/cvar/constant events. There will be some performance considerations with either of these approaches, but I think the impact can be minimized if done correctly. BTW, I've also been thinking about using a reference type as part of an alternative method caching strategy, but I haven't had time to fully work this out. (Basically, a CacheSite [such as InlineCachingCallSite] would obtain a MethodReference, which would remain valid for all time [though the (volatile) referenced method might change] . The MethodReferences would be cached at the metaclasses where the methods were referenced. An event listener mechanism would be used to keep them up to date. As I said, not fully worked out.) In general, I think we should consider building an event mechanism into JRuby 2 that will support listening for a number of internal event types. We should also consider exposing this mechanism through Ruby, via a gem or other optional module. Among other things, we could provide a superior (but non-standard and therefore necessarily optional) alternative to the rename-override-call_renamed approach of hooking events like :method_added. Some internal code could also be refactored to use the new event mechanism.
Hide
Permalink
Thomas E Enebo added a comment -

For the sake of this particular Jira issue, it strikes me that people will expect visible fields to be represented in Ruby-space as instance attributes.

The particular implementation details can be hashed out (I think the reference type/indirection impl works), but do we all agree this is a reasonable "least surprise" fulfilling enhancement? When the original user mentioned this, I just thought: "Duh...I wonder why we haven't done this yet".

Show
Thomas E Enebo added a comment - For the sake of this particular Jira issue, it strikes me that people will expect visible fields to be represented in Ruby-space as instance attributes. The particular implementation details can be hashed out (I think the reference type/indirection impl works), but do we all agree this is a reasonable "least surprise" fulfilling enhancement? When the original user mentioned this, I just thought: "Duh...I wonder why we haven't done this yet".
Hide
Permalink
Bill Dortch added a comment -

... it strikes me that people will expect visible fields to be represented in Ruby-space as instance attributes.

I'm not sure people really expect it – there are plenty of pure-Ruby types that do not expose all their internal state through ivars. And the case you cite raises the issue of whether we should expose protected fields. Also, JIRB output could become painful to look at if inspect always dumped all internal variables. And finally, it would become difficult to distinguish "true" ivars from pseudo-ivars. Some confusion and phantom support issues might arise.

Still, it is an appealing idea, and could probably be made to work, though possibly with some flags to control some aspects of the behavior.

BTW, this will be easier to do once we've broken the RubyObject/IRubyObject stranglehold, and can simply supply an alternative vars implementation for Java classes. JRuby 2...

Show
Bill Dortch added a comment - ... it strikes me that people will expect visible fields to be represented in Ruby-space as instance attributes. I'm not sure people really expect it – there are plenty of pure-Ruby types that do not expose all their internal state through ivars. And the case you cite raises the issue of whether we should expose protected fields. Also, JIRB output could become painful to look at if inspect always dumped all internal variables. And finally, it would become difficult to distinguish "true" ivars from pseudo-ivars. Some confusion and phantom support issues might arise. Still, it is an appealing idea, and could probably be made to work, though possibly with some flags to control some aspects of the behavior. BTW, this will be easier to do once we've broken the RubyObject/IRubyObject stranglehold, and can simply supply an alternative vars implementation for Java classes. JRuby 2...
Hide
Permalink
Bill Dortch added a comment -

re:

plenty of pure-Ruby types

meant to say "core" Ruby types, i.e., implemented in C or Java

Show
Bill Dortch added a comment - re: plenty of pure-Ruby types meant to say "core" Ruby types, i.e., implemented in C or Java
Hide
Permalink
Charles Oliver Nutter added a comment -

We've discussed this numerous times, but in general have decided not to expose Java fields as instance variables. They behave too differently, and the overhead of making instance-variable logic polymorphic just to support custom logic for Java classes does not seem like it's worth it. We have since provided other mechanisms for exposing fields (like field_reader, field_writer, etc), so I think exposing them as ivars is no longer necessary.

Show
Charles Oliver Nutter added a comment - We've discussed this numerous times, but in general have decided not to expose Java fields as instance variables. They behave too differently, and the overhead of making instance-variable logic polymorphic just to support custom logic for Java classes does not seem like it's worth it. We have since provided other mechanisms for exposing fields (like field_reader, field_writer, etc), so I think exposing them as ivars is no longer necessary.

People

  • Assignee:
    Charles Oliver Nutter
    Reporter:
    Thomas E Enebo
Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: