Re: [Wxruby-dev] Summary of naming problems

[Kevin Smith]

On Sun, 2003-06-22 at 20:16, Richard Kilmer wrote:
> I would really like Wx to become the standard graphical library for 
> Ruby because of its cross-platform reach and native widget approach.  

Me too!

> When you code a lot of Ruby and then run into a CamelCase library just 
> feels odd, and I think that if Wx becomes the standard graphical 
> library...that will be an issue.  I am just trying to look at this in 
> the long run.  If we say "let's stick with the Wx API for now" that 
> will likely be the API.

I'm not sure about your fear of the long run. It's pretty trivial to
create aliases for everything...although that means that anyone looking
at a wxruby program might see names_like_this or namesLikeThis (or
perhaps both in the same app!).

I was curious what other GUI libraries have done. Here's what I found:

It seems that the ruby bindings for tk, fltk, and gtk all use
ruby_naming. But the underlying libraries also use that naming
convention. 

Meanwhile, the ruby bindings for qt and fox use camelCase. And, not
surprisingly, the underlying libraries do as well.

The exception to that pattern seems to be carbon, which (if my quick
research was accurate), uses camelCase in the native library, but
ruby_naming in the ruby bindings.

I'm still undecided. I generally prefer camelCase, but agree that being
rubyesque has value, but am bothered by the amount of subtle mental
conversions that would be required to go with ruby_naming.

> I believe that the documentation could be converted more simply than 
> the code...the method parameters are different in WxRuby vs. C++ 
> anyway, so the documentation is going to have to be updated to some 
> degree.  

If we went with camelCase, the ruby bindings could match the python
bindings almost exactly. Since the existing docs already cover the
python bindings, there would probably be just a handful of doc changes
required.

> In the little utility I wrote to parse the latex and emit the 
> method names for you, it was not all that much of a stretch to think of 
> having it rewrite the documentation with the parsed/rewritten 
> methods/classes/constants.

True. But it is one layer of indirection away from the "real" docs. So
it will be more effort.

In the end, we can either "be like ruby", giving up mental compatibility
with the c++ and python versions, or we can "be like the c++ and python
bindings", forcing ruby coders to deal with camelCase. There still
doesn't seem to be a clear "right answer" there.

Kevin

P.S. Switching the library between camelCase and ruby_naming probably
took less than an hour. Switching all the sample programs took me
several hours! I had to run each one, trying every option, to be sure I
didn't miss something. Ugh.