Laurent Sansonetti
lsans****@apple*****
Thu Jun 8 09:49:15 JST 2006
On Jun 7, 2006, at 11:12 PM, Jonathan Paisley wrote:
>
> On 7 Jun 2006, at 15:36, Laurent Sansonetti wrote:
>
>> Someone here talked me about that calling convention that Rails is
>> using:
>>
>> obj.foo(:key => val, :key2 => val2, ...)
>>
>> and suggested that RubyCocoa uses it.
>>
>> I believe that this convention is prettier than the current symbol-
>> value-symbol-value..., and sounds more like Objective-C.
>
>> Tell me what you think,
>
> I must admit to rarely using either keyword form. I tend to go for
> the method_with_underscores.
>
> However, I can see that the hash form is more readable, and certainly
> paves the way for some day when Ruby has true keyword arguments.
>
I also prefer using the underscored notation.
Oh BTW, one thing I have been thinking about for a long time... it
would be really great if RubyCocoa could translate the general
underscored-notation when messaging the Objective-C world. For
example, to be able to call NSString.alloc.init_with_string("foo").
I really dislike having both CamelCase and underscored notations in
the same piece of code.
But this is just a personal thought... Just wanted to talk about this
later, but maybe this is the time to start the subject :-)
Technically speaking this should not be that hard, just some notation
conversion and caching things.
Another idea would be to use Ruby blocks more often in the API. For
example, that target/selector API used for example in NSControl could
use it in the same way the Ruby/GLib binding connects closure to
signals, e.g. my_button.signal_connect('button-pressed') { ... }.
Not sure if these ideas are interesting to other people, but in my
experience writing Ruby libraries, users really like Ruby'sh APIs.
The Ruby-GNOME2 libraries are IMHO a good example of what is a cool
Ruby'sh API, but this is just a personal idea.
> A sensible caching scheme would alleviate any concerns over
> inefficiency.
I will add some caching soon, and I anyway plan to do some general
benchmarking tests when everything will be finished, to be sure all
performances-related changes have been fruitful.
Laurent