David Koontz wrote:
In all the time I've been doing JI work, I've never wanted to write a
method name that wasn't the canonical Ruby style name. So, for me and
the people I've been working with, I don't think any intermediary name
is really wanted or needed. Ideally we would use the Ruby name in every
case and just pretend that setFoo on the Java class/interface is really
just written as foo=. So you would get my vote on making concrete
classes work like interfaces with regards to overriding a method. I do
agree that this presents some pitfalls if you implement both a foo= and
a setFoo method, although I would say you can do lots of stupid things
in Ruby and this would be no different.
So here's the methods I see as being intermediate:
given a Java method name isMyFoo that returns boolean...
1 isMyFoo is obviously needed
2 is_my_foo is an intermediate or partial Ruby name
3 myFoo is an intermediate
4 my_foo is an intermediate
5 myFoo? is an intermediate
6 my_foo? is ideal Ruby
The boolean case is a little harder than a non-boolean case, since the
attr* methods don't create question-marked versions. So I think in the
spirit of supporting attr* methods, we need to keep 4 for sure in all
cases. The others...well it's a really tough call for me. It feels like
if we removed 3 we'd have to remove 4. And it seems like 2 is necessary
as an analog to 1. So only 3 and 4 are candidates to be removed as far
as I can see, and that isn't really saving us a whole lot, is it?
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
