> The toolkit may care about the values of the identifier, but the
> programmer shouldn't (he won't). The first think I did writing my hello
> world FXRuby script was to do this:
>
> module Fox
>   class FXMainWindow
>     def FXMainWindow.identifier(*symbols)
>       instance_eval "#{symbols.join ', '}, ID_LAST =
>          enum(Fox::FXMainWindow::ID_LAST, #{symbols.length + 1})"
>     end
>   end
> end
>
> It should be possible to generalize this code to other classes.

I like this a lot. I still need to play with this a little bit but I have
the feeling this is going in the next release (with all appropriate credits
of course!)

Of course, I still want to move further away from this model if possible; it
would be more convenient if one didn't need to specify the message
identifiers at all (i.e. they are magically generated behind the scenes):

    button = FXButton.new(parent, ...)
    button.mapMessage(SEL_COMMAND) { |sender, sel, ptr|
        # handles the SEL_COMMAND message from this button
    }
    button.mapMessage(SEL_UPDATE) { |sender, sel, ptr|
        # handles the SEL_UPDATE message from this button
    }

but I have the nagging suspicion that there are some holes in this approach
that I haven't thought of yet ;)

> Great! By why keep the arguments if you can do without them. When you use
> them, the expression becomes unreadable. You still won't be able to
> remember with the 5th argument was about. The only exception is the use of
> named arguments (by symbol or string, which is possible with today's
> ruby!):
>
>       @button = Button.new('Click me', :border => 10);
>
> This is readable -- "Button.new('Click me', 10)" isn't. Is 10 the border?
> the font size? It becomes a short circuit in my brain rather than a short
> cut.

The large number of arguments is, as you might guess, a holdover from FOX's
C++ API. But it was a deliberate decision and part of Jeroen's design
philosophy (note: Jeroen is the designer and primary FOX developer). If
you're interested, you might check out the "Foreward" section of the FOX
documentation:

    http://www.fox-toolkit.org/foreword.html

I think it's a moot point, though; as we've already established, if you
don't want to specify all the arguments in the new() call, you don't have
to. What might be appropriate is for me to mix up the styles in the example
programs, to demonstrate that one has a couple of options for constructing
the widgets.

> Indeed I am not. I only spend 10 minutes looking over the samples (which
> DO use bad coding style :) and writing a simple hello world script. I
> wasn't trying to spread fud about FXRuby, but make a point about
> interfaces in general. It's good to hear the API design is of high
> priority in FXRuby!

The examples were "ported" from the C++ examples, usually with only the
minimal changes needed to make them work in Ruby. So you've got me there --
if it looks like C++ code written in Ruby, that's why. I'll try to
incrementally clean them up for future releases.

Thanks very much for the feedback, and please do check in on the FXRuby
development progress every now and then. Maybe it will win you over yet ;)