Re: Glib::Object->methods take a look at this...

["Ross McFarland" <rwmcfa1 neces com>]

A. Pagaltzis said:
> Well that *is* old hat. :) And it has multiple weaknesses. First,
> it can't tell class methods from instance methods - worse, it
> can't tell simple package functions from methods at all. It won't
> work very well for modules with mixed interface style. Second,
> there is absolutely no way to infer what happens if you call
> $obj->foo if a) sub foo does not exist but b) sub AUTOLOAD does..

true that it can't tell class static methods from object methods, but that
doesn't deminish the usefulness in this situation. if you have a Gtk2::Window
and you're looking for how to do something with it, a list of all of the
possible functions that can be called on it will 9 times out of 10 tell you
which one to use. from there you can call it with no params to get a usage
message to tell you the params. if their meaning is obvious you may never have
to look at the api docs. that was my point and this will work for that.

also this is a quick way to see what isn't implemented, if you see something
that's in the api doc, but doesn't show up in this list.

this would limit the usefulness for auto-complete type things b/c you'd get
function that weren't correct, but it would be better than nothing. with Gtk2
most all of the class static stuff is obvious, new's and such.

> So this approach is okay if you stick to some sort of
> convention(s) for naming functions and maybe a convention for
> where to describe in some datastructure what AUTOLOAD does.

we know that with Gtk/Glib there's no AUTOLOAD stuff going on so for it this
is/would be a non-issue. it was obvious going in that if you do AUTOLOAD stuff
this will buy you nothing, but i just wanted a list of a Glib::Object
derivatave's methods and this will do that.

the only only real downside is that this will display private functions
Gtk::ItemFactory::_create_item and such, but there are very few of those and
they're usually obvious.

> But for the general case, it's about useless and in fact there's
> no solution at all.

i wasn't nec. thinking in the general case, i was thinking about Gtk2-Perl.

-rm