|
|
|
[
Permlink
| « Hide
]
David Koontz - 19/Mar/07 03:39 AM
Public member variables are also not being added to the proxy class.
Perhaps there's a larger question here...how best to expose them? foo.bar looks for a bar() method on the foo object's class. This means that field accesses would require bar() and bar=() to be defined, incurring a method hit for all sets. But we may be constrained by what's practically possible in Ruby.
Are there other options? We already expose public static variables as methods (e.g. System.out) and I don't know of a better way, so perhaps it's already a moot point. I assume your comment about exposing the variables is with regard to the public variables? Since bar() and bar()= methods are how Ruby operates it would make sense to map public in that manner as well although I do see your point about the extra method calls. Right now you have to use reflection to get at them so I think any implementation is probably better than that, performance wise.
Public member variables should be there (see JavaProxy.setup_attributes in builtin/javasupport/proxy/base.rb). See, for example,. java.awt.GridBagConstraints. They might be getting clobbered, though, by (generated) shortcut method names – my fix for
However, if a public field name is the same as a declared public method name, the method will win. We could consider a naming strategy to get around this; prepending an underscore to the field name, for example, or appending '_field'. Another possibility is using the [] / []= operators, since this won't collide with any Java names. For example: an_object = AJavaClass.new
an_object[:a_field_name] = a_value
Thoughts? -Bill Bill, go ahead and file another issue for the collision if it's still outstanding. You're right about the original issue being fixed though, so I'm marking this resolved.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||