wxruby users - Apr 2004 - TRW: getters and setters

Hi all,

I mentioned this on the forum but wasn''t sure if
anyone was paying attention.  I was just wondering if
it would be possible to replace the
get_something/set_something style methods with the
more Rubyish something/something= style (i.e. uniform
access).

For example, the Button class currently has
button.get_label and button.set_label("foo").  It
would give me warm, fuzzy feelings if I could do
button.label and button.label = "foo". :)

Just a thought.

Regards,

Dan

PS - TRW == "The Ruby Way" before you ask.


	
		
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash

> I mentioned this on the forum but wasn''t sure if
> anyone was paying attention.  I was just wondering if
> it would be possible to replace the
> get_something/set_something style methods with the
> more Rubyish something/something= style (i.e. uniform
> access).
> 
> For example, the Button class currently has
> button.get_label and button.set_label("foo").  It
> would give me warm, fuzzy feelings if I could do
> button.label and button.label = "foo". :)
While it sounds nice sometimes the get/set methods have multiple
parameters,
so it obviously won''t fit all such methods.

<rant> 
And also, the ListCtrl#get_item method changed API between 0.2 and 0.3.
So I had to debug and fix my program to match. But now the get_item and
set_item
methods have unrelated APIs!
I''m just waiting here for the next version, quietly polishing my rifle
to hunt
the next such change.
</rant>

Daniel Berger wrote:
> I mentioned this on the forum but wasn''t sure if
> anyone was paying attention.  
I did see it there, but hadn''t yet had a chance to respond. Posting to 
this list is probably a better mechanism for requests like this. It''s 
easier for me to respond, and it will reach more of the core folks who
are likely to influence the design.
> It would give me warm, fuzzy feelings if I could do
> button.label and button.label = "foo". :)
I don''t think we should _replace_ the existing get_label and set_label 
methods, but it seems reasonable to add Ruby-style accessors. Hmmm. 
Couldn''t I just set ''label'' and
''label='' as aliases?

Kevin

Mehr, Assaph (Assaph) wrote:
> While it sounds nice sometimes the get/set methods have multiple
> parameters, so it obviously won''t fit all such methods.
Good point.
> <rant> 
> And also, the ListCtrl#get_item method changed API between 0.2 and 0.3.
> So I had to debug and fix my program to match. But now the get_item and
> set_item methods have unrelated APIs!
> I''m just waiting here for the next version, quietly polishing my
rifle
> to hunt the next such change.
> </rant>
Frustration noted. I''ll try to do a better job of clearly marking API 
changes from version to version. I guess this is a good example of the 
concerns Nick had about calling this a version 1.0 when the API hasn''t 
really stablized yet.

There are a number of API calls that will probably change in the future 
to match wxPython. My working assumption is that any place that wxPython 
deviated, we should also do so. Except for overloaded constructors, 
probably.

Kevin

>> <rant> 
>> And also, the ListCtrl#get_item method changed API between 0.2 and
0.3.
>> So I had to debug and fix my program to match. But now the get_item
and
>> set_item methods have unrelated APIs!
>> I''m just waiting here for the next version, quietly polishing
my
rifle
>> to hunt the next such change.
>> </rant>
>Frustration noted. I''ll try to do a better job of clearly marking
API
>changes from version to version. I guess this is a good example of the 
>concerns Nick had about calling this a version 1.0 when the API
hasn''t
>really stablized yet.
>There are a number of API calls that will probably change in the future
>to match wxPython. My working assumption is that any place that
wxPython 
>deviated, we should also do so. Except for overloaded constructors, 
>probably.
Don''t get me wrong, I still love the toolkit and appreciate the work
you''re doing. If I had spare time I might contribute. As things stand,
I
just have time to provide a user''s perspective. I''m on WinXP
if that
matters to you.

As for API changes, I use the wxWindows 2.4.2 HTML help files. Knowing
how to translate the method names and use the wxPython remarks makes a
great reference. The better you adhere to the conventions the easier it
is for me to use.

Cheers,
Assaph

ps Wx::VERSION_STRING reports "wxWindows 2.4.1". How do I find the
wxRuby version? Plus, any reason it''s not 2.4.2?

Mehr, Assaph wrote:
>
> Don''t get me wrong, I still love the toolkit and appreciate the
work
> you''re doing. If I had spare time I might contribute. As things
stand, I
> just have time to provide a user''s perspective. I''m on
WinXP if that
> matters to you.
>
> As for API changes, I use the wxWindows 2.4.2 HTML help files. Knowing
> how to translate the method names and use the wxPython remarks makes a
> great reference. The better you adhere to the conventions the easier it
> is for me to use.
Getting feedback from real, live use of the wxRuby API (and documentation,
as you noted above) is extremely valuable. This contribution of yours a
real, and appreciated.

Curt

Mehr, Assaph (Assaph) wrote:
> ps Wx::VERSION_STRING reports "wxWindows 2.4.1". How do I find
the
> wxRuby version? Plus, any reason it''s not 2.4.2?
I would have to double-check, but I don''t think there is any way to
find
out the wxRuby version. This is something I plan to add in a future 
release (it is on my TODO list).

I believe Curt builds the Windows binaries with wxWindows 2.4.1. I am 
not sure why. At one point, I was having trouble with 2.4.2 on Linux, 
but now it works fine.

Kevin

> Getting feedback from real, live use of the wxRuby API 
> (and documentation, as you noted above) is extremely
> valuable. This contribution of yours a real, and appreciated.
My pleasure. Hey, I''m getting a better toolkit for it :)

Another API snafu: ComboBox#get_value does not exists but #get_label
does and appears to do the same thing.

Cheers,
Assaph