Java package modules, take 2
----------------------------
Key: JRUBY-885
URL: http://jira.codehaus.org/browse/JRUBY-885
Project: JRuby
Issue Type: New Feature
Components: Java Integration
Affects Versions: JRuby 1.0.0
Reporter: Bill Dortch
Attachments: java_modules.patch
Another approach to Java package modules:
- One module per package (regardless of the number of name segments)
- Camel-cased (much easier on the eyes than ALL_CAPS)
- No ambiguities regarding package vs. class
{code}
java.lang.Object #=> Java::JavaLang::Object
java.awt.Color #=> Java::JavaAwt::Color
java.awt.color.ColorSpace #=> Java::JavaAwtColor::ColorSpace
org.jruby.javasupport.Java #=> Java::OrgJrubyJavasupport::Java
class Java::JavaLang::Object
def foo
puts "foo!"
end
end
{code}
Classes in the default package are placed under module Java::Default, so the
pattern is always Java::PackageModuleName::ClassName. (There's no package
called "default" (reserved word), so this won't collide with anything.)
The only downside I can think of is that this approach doesn't create a
containment hierarchy of modules, but just now I can't think of a reason that
matters.
I haven't reworked Java::const_missing yet, but it shouldn't be too hard to
split the camel-cased package names to get dot.separated names that can be
passed to JavaUtilities.get_proxy_class. (Right now, the example shown of
opening java.lang.Object won't work unless you've already pulled the class in.)
Patch attached, give it a whirl. (The patch also makes Java::Package a (nearly)
blank slate, as I was running into collisions in testing.)
Comments?
-Bill
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
