More rubish API

Desktop wxRuby
1

Hi,
Sometimes I find places in WxRuby API which seem to me not quite Ruby
way
compatible. :slight_smile:
I know (it’s written somewhere on the wxruby site), that there is an
acvity
to make WxRuby more Rubish.
I don’t feel enough confident in Ruby or WxRuby to fully participate,
but
I’d like to point to some places which could be improved.
Where is the best place to do it? This mailing list or bug tracker or
somewhere else? :slight_smile:

For example, that’s what I’ve noticed while examining
RichTextAttr#apply:
“Applies the attributes in style to the original object, but not those
attributes from style that are the same as those in compareWith (if
passed).
See also RichTextAttr#combine for a function that does almost the same
but
returns a new object instead of modifying the original object.”

I’d mark combine as deprecated and use apply! instead, because that’s
what
exclamation mark is for. What do you think?

Best regards,
Kirill.

2

What I also would like to propose is to make set-methods
“chainable”.Currently
I have to do the following:
style = Wx::RichTextAttr.new
style.set_font_face_name(“Verdana”)
style.set_font_size(10)
I would like to do:
style = Wx::RichTextAttr.new
style.set_font_face_name(“Verdana”).set_font_size(10)
etc.

This can be easily done by returning self object after modifying it.

I also would like to point that set_text_colour and
set_background_colour
are named in a british manner (OUR), which is fine for
language, but is not traditional for IT, which uses color (OR). It looks
reasonable to change or at least alias this.

Thanks,
Kirill

2008/11/5 Kirill L. [email protected]

3

Kirill L. wrote:

Sometimes I find places in WxRuby API which seem to me not quite Ruby
way compatible. :slight_smile:

Yes, me too. It’s pretty much a straight port of the C++ wxWidgets API,
with a few additions to make it more comfortable in ruby (eg
accessor-like method names, using symbols to name event handlers,
keyword constructors for Windows). And the wxWidgets API itself is not
especially consistent across classes in the way that similar methods
work.

I know (it’s written somewhere on the wxruby site), that there is an
acvity to make WxRuby more Rubish.

This activity - which was under the project ‘wxSugar’ has kind of been
in abeyance. Basically my time has been focussed on extending and
correcting the SWIG wrapping. This stuff is pretty hard for newcomers to
do - things like dealing with cross-language memory handling and
wrapping virtual classes. But much of the syntax enhancement work can be
done - or at least prototyped - in ruby.

We’ve also tried to keep the API stable since around version 1.9.2, so
this has limited scope for big changes. But I would see wxRuby 3.0 as
the place to be more radical and ruby-ify the API. I think then we also
have a better view of all the places where changes might be desirable,
to increase consistency.

I don’t feel enough confident in Ruby or WxRuby to fully participate,
but I’d like to point to some places which could be improved.

Any contributions and discussions on these topics are very welcome.

Where is the best place to do it? This mailing list or bug tracker or
somewhere else? :slight_smile:

Probably the wxruby-development mailing list for detailed syntax
discussions.

For example, that’s what I’ve noticed while examining RichTextAttr#apply:
“Applies the attributes in style to the original object, but not those
attributes from style that are the same as those in compareWith (if
passed).
See also RichTextAttr#combine for a function that does almost the same
but returns a new object instead of modifying the original object.”

I’d mark combine as deprecated and use apply! instead, because that’s
what exclamation mark is for. What do you think?

I’d agree - but at the same time, I’d say it’s important to make this
change across all places it’s relevant at the same time. There are a few
other methods I think that have this pattern.

alex

4

Kirill

Thanks for the discussion.

Kirill L. wrote:

What I also would like to propose is to make set-methods “chainable”.
Currently I have to do the following:
style = Wx::RichTextAttr.new
style.set_font_face_name(“Verdana”)
style.set_font_size(10)
I would like to do:
style = Wx::RichTextAttr.new
style.set_font_face_name(“Verdana”).set_font_size(10)
etc.

I’m not generally a fan of method chaining - to me your second example
is less clear than your first. It’s 40 or 50 characters without any
white space.

I’d use a keyword constructor here, or a more declarative set of
statements:

attr = Wx::RichTextAttr.new( :font_face_name => ‘Verdana’, :font_size =>
10 )

or

attr = Wx::RichAttr.new
attr.font_face_name = ‘Verdana’
attr.font_size = 10

The second should already work.

This can be easily done by returning self object after modifying it.

Sure, if you would like this change, you can implement it yourself right
away. Add something like this to your personal wx_additions library:

class Wx::RichTextAttr
instance_methods.grep(/^set/) do | method_name |
old_method = instance_method(method_name)
define_method(method_name) do | *args |
old_method.bind(self).call(*args)
self
end
end
end

I also would like to point that set_text_colour and
set_background_colour are named in a british manner (OUR), which is
fine for
language, but is not traditional for IT, which uses color (OR). It
looks reasonable to change or at least alias this.

Hehe. I’m British and this is my single favo_u_rite feature of wxWidgets
and wxRuby. To replace them in the core lib with nasty US mis-spellings,
you’ll have to prise them from my cold dead fingers. :slight_smile:

Again, ruby makes it easy to change if it bothers you:

Wx::Color = Wx::Colour
alias :get_background_color :get_background_colour

etc

cheers
alex