Should Ruboto alias Android callback methods like onCreate, onResume, and onPause ?

[donV]

Hi all!

I am seeking opinions.  It may or may not lead to a change.

When designing the callback feature of Ruboto we have added an aliasing feature for the callback methods.  That means that for the classes that are specially handled by Ruboto (Activity, BroadcastReceiver, and Service), and any classes generated by the Ruboto tooling using "ruboto gen subclass", we check for a snake case method if the camel case method is not implemented in the Ruby subclass.

It seemed like a nice feature at the time.

Recently two arguments against the feature have been raised:

1) By enabling the snake case method use, code corresponds less to the Android documentation.  JavaDocs and examples refer to onCreate, not on_create.  By using the camel case method name, code is kept closer to the documentation, and it is clearer that this is not some independent method, but an implementation of a defined interface.  Googling for examples using the method will probably fail to find snake case instances.

2) The snake case versions of the method names cannot be used everywhere.  JRuby itself does NOT alias method calls from Java to Ruby, only from Ruby to Java.  That means that if you use the direct subclassing feature to create a Ruby subclass of a Java class, method calls from Java to your class will NOT be aliased, and you cannotuse the snake case method names.  This is inconsistent and maybe unexpected.  I have forgotten it myself a couple of times.

As with any feature, removing it would simplify the code, and we would need to have a period of deprecation with warning before we could remove it completely.

What do you think?  Should we keep this feature, or remove it?  Any thoughts are appreciated.  Final decision is of course made in the core team :)

[Robin2]

I can't understand why Ruby/JRuby with all its claims to simplicity and conciseness prefers snake_case. It is much easier to type snakeCase than snake_case and it is one character shorter!

And I strongly favour using Android style for anything that is used or can be used straight from the Android documentation. Trying to figure out Ruboto was a nightmare until I had deconstructed the basic application into Android style and could see how it relates to the Android documentation.

This is an area where the needs of newcomers should be paramount.

Rather than have a period of deprecation why not simply move on to the next version with the new style and simpler code and leave the old version available for those that need it. Periods of deprecation just treble the complication.

...R

On Monday, January 28, 2013 7:53:16 PM UTC, donV wrote:

Hi all!

I am seeking opinions.  It may or may not lead to a change.

[Gerard Fowley]

I think keep it, and expand it (see response to #2). My preference is for snake_case over camelCase.

About the issues listed:

1) Correspondence with Android documentation:

Some understanding of different concepts and language are to be expected when developing in a multi-language environment. A prominent note about the minor difference in method naming conventions in documentation or in comments for Ruboto generated classes would help, but it seemed clear enough to me from the start.
 
2) The snake case versions of the method names cannot be used everywhere:

I did run into the callback method name issue with direct subclassing, but it wasn't hard to understand, and renaming methods in my single case was an easy fix. Long term, I would prefer a meta-programming idiom for direct subclass usage that allows for automatic / specified creation of callback methods to create Java-named interface methods - something that feels like the ActiveRecord Model class.  

In a multi-language environment, my inclination is to prefer the idioms of the developer-facing language because that's where I'll spend most of my time. I think as we wrap more of the Android API (and document it), we'll move in that direction anyway (the recent question about accessing a Cursor in an Enumerable-like fashion is a good example). Java-isms like camelCase will soon stick out like a sore thumb.

tl;dr: IMHO, Ruboto is for developing Android apps in Ruby, let Ruby-isms prevail.

-gf-

Gerard Fowley
CISSP
Information Security Consultant
Principal @ Iqeo LLC
gerard...@iqeo.net
508-769-9617
http://iqeo.net

--
You received this message because you are subscribed to the Google Groups "Ruboto (JRuby on Android)" group.
To unsubscribe from this group, send email to ruboto+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Rystraum Gamonez]

I prefer snake case as a ruby developer but as a relative new comer to Ruboto, it wasn't readily apparent to how the snake case methods relate to the camel case ones.

I think it's much simpler to use the camel case even if it's not a ruby-ism. We get so many wins (documentation, simpler code, less gotcha's, closer to android) for relatively small losses (annoying the developer). Just my 0.02

To unsubscribe from this group and stop receiving emails from it, send an email to ruboto+un...@googlegroups.com.

[Joshua Morine]

 I for one prefer snake_case in ALL of my code, in any language. I'm used to it, and I personally find it easier to read. With that said however, Android development is complicated enough, and having the method names more closely
mirror the method names in the Android documentation seems like a good thing. Combine that with your point about JRuby not aliasing method calls from Java to Ruby, and I think it would make sense to switch to only camelCase names.
But that's just my 2cents as a fairly new Ruby programmer, and a very noob Ruboto programmer.

[Keith Bennett]

I use snake case everywhere except where my function will be called by Java as an interface implementation or method override.  Not knowing to do this bit me once, but then I learned.  When I did, it made sense to me.  I don't think it's an excessive burden to the JRuby developer to understand to use the camel case name when Java is calling a function by that name.

I certainly wouldn't mandate using only camel case names throughout a JRuby application; that would be overkill -- but that's because I prefer snake case; if I didn't it would make more sense; but then you'd still be going against the language convention.  Also, that would create an obstacle to adoption by many Rubyists (justified or not).

- Keith

---

Keith R. Bennett

http://about.me/keithrbennett

[Scott]

I feel we should support the camelCase and retain support for snake_case, allowing the developer decide what they want to use.

I does make the Ruboto code more complex to support this, but 

1) Does not force developers to do it one way

2) We're already in a mixed environment with some aspects of both

3) I don't want another rewrite of all of our existing samples and tutorials