I don't think it's a good idea to pollute things here. With JRuby
being the name of the project, it's more comfortable to keep it
together "jruby_class_loader", but creating additional alternate
method names for any other instance goes down the wrong road.
Think about how to describe the Java methods in JRuby environment:
...
underscore rather than camel-capped, all lowercase letters
...
getters/setters : "get" and "set" are removed and can be accessed as follows:
getBasicThing() => basic_thing
setBasicThing(String foo) => basic_thing = "foo str"
*** One special case exists with the word "JRuby", this word will not
be separated in methods that have been "Ruby-ized" i.e.
invokeJRubyThing() => invoke_jruby_thing
getJRubyBasicThing() => jruby_basic_thing
setJRubyBasicThing(String foo) => jruby_basic_thing = "foo str"
Just my $.02,
M
On Nov 17, 2007 5:01 PM, MenTaLguY <[EMAIL PROTECTED]> wrote:
> I think producing jruby_class_loader from getJRubyClassLoader (instead
> of j_ruby_class_loader) should be pretty non-controversial. However,
> the other issue touched on in the bug are the "hybrid" accessors like
> jRubyClassLoader.
>
> In most cases those work out better than the getJRubyClassLoader case;
> e.g. getBasicThing becomes basicThing -- but the question remains: if we
> already have getBasicThing and basic_thing, should we be generating
> another method that doesn't exist in Java, yet is named according to
> Java conventions?
>
> -mental
>
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
