I was toying around with adding a to_s function to wxPoint (and probably
to some other classes). I''m wondering if this is a good idea or not
and
if so, is it best to use %extend or put it into something like wxSugar
or the ruby parts of wx?
My initial implementation is:
%extend wxPoint {
VALUE to_s()
{
char buffer[40];
sprintf(buffer, "%d,%d", self->x, self->y);
return rb_str_new2(buffer);
}
}
Thoughts? It might even be better to implement an inspect and use that
instead (or in addition).
Roy
Roy Sutton wrote:> I was toying around with adding a to_s function to wxPoint (and probably > to some other classes). I''m wondering if this is a good idea or notI like the idea. Objects should give an informative string representation where possible (Point, Size).> if so, is it best to use %extend or put it into something like wxSugar > or the ruby parts of wx? >Sounds like a core feature, not sugar. My preference would be to implement a to_s method in the ruby parts of wx (overriding ruby''s Object.to_s).> Thoughts? It might even be better to implement an inspect and use that > insteadI think the Ruby expectation is that to_s is called by inspect as a default strategy, so maybe just do to_s. PS - thanks for all the bugfixes. I had a good session running Weft QDA on wxruby2 on Linux, and just reporting bugs it turned up. If you don''t mind I''m going to move your typemap for get_selections into ListBox.i as it''s not used anywhere else. cheers alex
Alex Fenton wrote:> PS - thanks for all the bugfixes. I had a good session running Weft QDA > on wxruby2 on Linux, and just reporting bugs it turned up. If you don''t > mind I''m going to move your typemap for get_selections into ListBox.i as > it''s not used anywhere else. >Sounds good to me. I noticed that, too. Roy