Re: Return values from gtk2 widget (void) methods

[Dermot Musgrove <dermot glade perl connectfree co uk>]

Guillaume Cottenceau wrote:
> Dermot Musgrove <dermot glade perl connectfree co uk> writes:
>
> > Hi,
> >
> > Does Gtk2-Perl return perl or C success values?
> >
> > I am not sure how Gtk-Perl handles this but at the moment, AFAIK, 
[...]
> Do you have a code example where this problem bites you?
Hi Guillaume,

It occurred when I was writing Gtk2::Test - with (little) research I found
that many of the calls I tested return perl undef on success but some 
return other things:

Call (success)                  Gtk-Perl                Gtk2-Perl
--------------                  --------                --------
Gtk2->init                      1                       0
Gtk2::Window->set_position      undef                   undef
Gtk2::HBox->add                 ref to widget added     undef
signal_connect                  connect id              connect id

I have only looked at a few calls but I note that:

1) Gtk-Perl is inconsistent in what it returned.

2) Gtk2-Perl is (differently) inconsistent.

3) Many (most?) calls in both modules return undef.

4) perldoc perlfunc says:
  In general, functions in Perl that serve as wrappers for
  system calls of the same name (like chown(2), fork(2),
  closedir(2), etc.) all return true when they succeed and
  `undef' otherwise, as is usually mentioned in the
  descriptions below.  This is different from the C
  interfaces, which return `-1' on failure.  Exceptions to
  this rule are `wait', `waitpid', and `syscall'.  System
  calls also set the special `$!'  variable on failure.
  Other functions do not, except accidentally.

So what should happen? As a perler, I like the idea of returning 'true
when they succeed and 'undef' otherwise.' like system calls. Success is
easy to spot and failures are not easily confused with anything else.

I like the idea that you could call '$w->method && $w->another_method'
and this is IMO more perlish. 

I don't understand the gtk2 error handling but is it possible to return
success/failure centrally? 

However, whatever is decided, I think that it should be consistent.

What do people think?

Regards, Dermot