ok, i will submit the suggestions as feature requests.

a completely new API in a different module would not only be more robust than the method_missing hack (which slows down old camelcased code with an extra indirection for each method call) – it also brings the chance to do a more sophisticated redesign. i.e. resolve the “create issue” and much more.

if you finally deside to code up a new API module i would like to volunteer to join the project
as you might know i have quite some experience because i actually did the same thing for foxguib. well, back then i was more of a hacker than a software engineer so i would like to do it again and well this time. also i would like to work together with a even much more experienced guy like you. and finally, i have a lot of ideas for improvements and simplifications based on usage experience of fxruby.

– henon

Having used a lot of FXruby code in FreeRIDE, I’d say that I can live with the FX prefix. If you include Fox you don;t have to specify Fox:: anyway and I would even argue that, on the contrary, having the FX prefix and even the camel case makes it easy to distinguish method names that deal with UI stuff from others like standard libraries.

Thanks again for FXRuby. It’s a great help for my main Ruby project.

FWIW, I think underscores instead of camel case is a great idea. The camel case bothers me more than it probably should.

I also like your namespace proposal. Since we have to live with a Fox-Ruby “bridge” no matter what, we may as well take advantage of it and make the names clearer. I don’t think it will make it any harder to use the API docs.

*Jim*, I had wondered if the proposed approach was an “abuse” of @method_missing@ and @const_missing@, or if there were other complications that I hadn’t considered. I will also consider just coding-up an add-on library that provides aliases and renames for the class and method names, per your suggestion.

require ‘fox/newapi/whatever’

module Fox
FXButton = Button
end

Method aliasing could do the same for the camelcase issue. The advantage is that you don’t need const/method_missing (which can be fragile is not done carefully). The downside is a lot of explict renaming and aliasing that would need to be maintained (but remember, automation is your friend).

Just some thoughts.

lyle, i am glad you decided to make fxruby more a ruby-style library as opposed to a authentic copy of the c API with all it’s flaws. i fully respect and support this decision!

there is annother thing which i want to suggest: please add default arguments for all constructor parameters with index > 0.
i mean: a default text for Button, default settings for Mainwin, etc. this would make the API even more easy to use:

include Fox
app=App.new
MainWin(app){|mw|
Button.new(mw){|button|
button.text = “Click Me”
…
}
}

the motivation for this is: i often get confused with the different sets of parameters in widget constructors. Some have a message target in the constructor, some don’t. to quickly code a gui it is most annoying to look up the parameterlist for every constructor in the docs. the problem is not their quantity (there are 1-4 parameters that don’t have default values in every widget constructor) – it is the inconsistency that makes it hard to remember.
apart from that it makes automatic code generation hard. for foxguib i decided to subclass every foxwidget to provide uniform constructors and to resolve some other inconsistencies in the API. since then i have allways used the simplified API (the fx library that is required by all foxguib-generated code) when i wrote gui-code by hand, because it was faster. would be great if fxruby provided uniform constructors.

annother thing that i often miss: a visible=(bool) method for Fox::Window. it is inconvenient to map a boolean variable to show / hide.

there are much more suggestions which i currently fail to recall. i will tell you later if you are interested.

– henon

In fact, my new project, Lumos, does not rely on any any prefixing, and while this gives somewhat more reasonable code, I’ve already found quite a number of cases where the namespace must be explicitly used to disambiguate symbols.

Even though that’s exactly what namespaces are for, of course, it still looks a bit inelegant compared to the alternative, and it makes it less transparent to determine which library a symbol comes from in larger software projects using several libraries.

I’m not sure to what extent the arguments above apply to [FX]Ruby, but I’m sure at least some of them do.

Jeroen

Anyway, I think it’s a bold move, and it’s worth the problems. The only notable difference will be to know how to search for the right method or class in Google if you want to search the Fox documentation rather than the FXRuby one.

I think you have many variables and I hope people will help to decide on this.

Cheers.