Re: Can't add new GTK 2.16 methods to GtkStyle

[Kevin Ryde <user42 zip com au>]

Torsten Schoenfeld <kaffeetisch gmx de> writes:
> 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".

Oh, well, you hope as a "social" matter when a subclass overrides it
does so in a kinda compatible way, so things you could do on the
superclass still have, mostly, the same result.  There must be some oop
jargon for degrees of extending, narrowing, or whatnot of subclass
method semantics must there?

> â Make Gtk2::Style::get() call gtk_style_get(), but leave
> get_property() alone. This has a precedent in Gtk2::TreeModel.

That's the one I like the sound of.

> â Use different names for the wrappers,
> e.g. Gtk2::Style::get_style_property() for gtk_style_get_property().

That'd be optional really.  Using such a name would make it clear it's a
style property being fetched.  Conceivably you might ask
can('get_style_property') in some generic kind of code.  But I'd expect
plain get() would be plenty for normal use.

Incidentally, there's no "list_style_properties" or similar for
available names is there?  To try to make its funcname match up too ...

> This has the disadvantage of deviating from the usual mapping from C
> function names

Of course at the C level there's no clash between names
    g_object_get_property()
    gtk_style_get_property()
only in to abbreviating them to be methods.  I suppose the odd clash
like that is inevitable if the C funcs don't have an eye to becoming
methods :-)


Emmanuel Rodriguez <emmanuel rodriguez gmail com> writes:
> We should probably consult this with the
> developers of the other GTK bindings as they might be in a similar
> situation.

Has pygtk got to this point?