Kevin Ryde wrote:
In generic code, you can never be sure that calling get_property() on an object will invoke Glib::Object::get_property(). You'd have to fully specify the method name to be sure.Really? It seems a bit un-oop-ish to give a full name, since if I'm not mistaken it would bypass anyone else's subclassing too (though I can't think of much besides call snooping that a subclass might legitimately do).
Yes, calling get_property() by its full name would bypass any overrides from subclasses. But I think that's fair; if you want to do unusual things when get_property() is called, do it in the GET_PROPERTY() vfunc.
Would the code in tie_properties() be giving full names? The unhappy surprise for a generic bit like tie_properties() would be that get_property / set_property don't match what list_properties, find_property and the notify:prop signal name stuff say. Because there's no properties on GtkStyle I suppose not too much can go wrong. But in the worst case you could imagine a different get_property may even be incompatible for an object inspector, if someone has been walking all objects with Devel::FindBlessedRefs or the like and hoping the names from list_properties can be accessed with get_property.
These are good points. There might be a lot of code out there relying on get_property() being Glib::Object::get_property(). I still think that's broken, since there's no guarantee that subclasses avoid naming methods "get_property". But maybe we should declare this a case of "don't do that!".
So, if we want to install such a "social rule", we have to adhere to it in Gtk2::Style too. As I see it, there are two ways to do that:
• Make Gtk2::Style::get() call gtk_style_get(), but leave get_property() alone. This has a precedent in Gtk2::TreeModel. But unlike in the Gtk2::TreeModel case, the C API also provides gtk_style_get_property(), and people seeing that might expect that calling get_property() on a Gtk2::Style invokes it.
• Use different names for the wrappers, e.g. Gtk2::Style::get_style_property() for gtk_style_get_property(). This has the disadvantage of deviating from the usual mapping from C function names to Perl method names. And what would we call the gtk_style_get() wrapper? Or would we only provide get_style_property()?
Should we do one of the above, or leave things as they are now? What do you all think?