[Wxruby-dev] Summary of naming problems

[Kevin Smith]

Ok. I've tried to figure out a way out of all of this. So I laid out all
the naming problems that I'm aware of right now. Here are the C++
wxWindows naming categories I've found, with examples:

CLASS
 wxWindow

CLASS METHOD
 GetPosition

GLOBAL METHOD
 wxMessageBox
 EVT_MENU

CONSTANT, PRE-DEFINED OBJECT, PTR TO PRE-DEFINED OBJECT
 wxSUNKEN_BORDER
 wxLIGHT_GREY
 wxNullColour
 wxDefaultPosition
 WXK_TAB

Quite a mess, as you can see. Recently, I have been trying to "rubify"
all of this, but have ended up where virtually nothing in wxruby is the
same as wxWindows for C++ or Python. I now believe that's a mistake.

What if we try to stay as close to the original as possible? We would
only change conventions when Ruby *requires* us to, such as class names
starting with an upper-case letter. Here's the result (I think):

CLASS
 WxWindow (changed)

CLASS METHOD
 GetPosition (same)

GLOBAL METHOD
 wxMessageBox (same)
 EVT_MENU (same)

CONSTANT, PRE-DEFINED OBJECT, PTR TO PRE-DEFINED OBJECT
 wxSUNKEN_BORDER
 wxLIGHT_GREY
 wxNullColour
 wxDefaultPosition
 WXK_TAB

The class methods and some "global" (actually module) methods would
start with upper case, but Ruby doesn't seem to mind that. Some
"constants" would start with lower case, but they could be implemented
as methods that return the underlying constant, so users wouldn't try to
change the value.

The big advantage is that there is only ONE change from the existing
wxWindows documentation. We would match not only the C++ version, but
also wxPython. To me, that seems worth it. We can always try to figure
out a more Rubyesque set of wrappers later, which would probably have to
include their own full set of documentation.

I'll probably postpone any coding on this for a week or so, hoping to
get more input before making more changes. I'll focus on migrating more
classes to templates, which will make these changes slightly easier
whenever I do them.

I know I keep asking different questions, but I do appreciate any
feedback that folks have. These questions really will set the flavor of
wxruby for the next few years (?), so they're pretty important. You can
probably tell that I'm not a great dictator.

Thanks,

Kevin