Torsten Schoenfeld <kaffeeti...@gmx.de> writes: > > What if gtk_text_view_new_with_buffer some day changes such that it is > not equivalent to this anymore?
That'd be the danger, if new_with_buffer doesn't document what it actually does. The gtk_menu_item_new_with_label is probably an example of that, changing from explicit child creation to going through a label string property. Maybe it depends which is worse, a method like new_with_buffer() that doesn't work in as much as it doesn't make a "new" of your subclass, versus coding some assumptions about what such a method should do. I expect a lot of subclasses might be faced with that dilemma, if the wrappers could try to address it. I suppose it doesn't come up in C code since methods are not inherited. You don't have a my_subclass_new_with_buffer() unless you make one yourself. The perils of C to OOP mapping, eh. > What we could do, I guess, is to adjust the xsub for > gtk_text_view_new_with_buffer such that it re-bless()-es the created > object into the package name given as the first argument. That doesn't work for a proper GObject subclass does it? Enough for a perl class, but not for a new gtype. -- It is most gratifying that your enthusiasm for our planet continues unabated. As a token of our appreciation we hope you will enjoy the two thermonuclear missiles we have just sent to converge with your craft. To ensure ongoing quality of service your death may be monitored for training purposes. Thank you. _______________________________________________ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list