JRuby (please use github issues at http://bugs.jruby.org)
  1. JRuby (please use github issues at http://bugs.jruby.org)
  2. JRUBY-1572

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

        Hide
        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
        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
        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
        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
        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
        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
        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
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: