Re: [pygtk] Overriding GObject methods in Python

[John K Luebs <jkluebs luebsphoto com>]

On Mon, Nov 27, 2006 at 05:08:28PM +0100, Hrvoje Nikšić wrote:
> On Sat, 2006-11-25 at 03:49 +0100, John K Luebs wrote:
> > If it's only a prototype, then it is assumed that large portions of
> > the system may need to be rearchitected.
> 
> Note that I meant prototype in the "working model" sense, not in a
> "throwaway"/"proof of concept" sense.

Well you contradict yourself here, because according to you this
prototype didn't work, so it wasn't a "working model". Regardless of the
semantics, large projects should have time budgeted for a "throwaway",
no matter what you want to call it.

> > Anyway, what you are asking for cannot be done with the traditional 
> > hammering out of C and C++ code.
> 
> The idea is to reuse GObject facilities where possible (e.g. types,
> inheritance, signals, GValues), and simply implement the appropriate
> vtable semantics overridable at runtime.  I was wondering if anyone else
> has stumbled on this and already solved it.

This is precisely what pygtk tries to do.
> 
> > Have you looked at how pygtk is built.
> 
> Yes.  The problem with PyGTK is that it adds new C code for each GTK
> class whose methods must be overridable from Python.  That works well
> for GTK which is fairly static, but would be a hassle in a system with a
> number of evolving classes.
>
Since C and C++ are not type rich and do not provide a type information
interface (C++ has RTTI, but it adoption is poor and it's a joke), there
is absolutely no way you can do what you want without some form of IDL
("simple") or C parser (not so simple) that generates the necessary
glue.

I can't see what is wrong with the way pygtk does things other than the
fact that you have to provide defs. Depending on how one writes their C
code, the right parser and generator it would be possible to do away
with the defs.

The C code that you're talking about is automatically generated, so I
don't think that it would be a problem even with many changing classes.

You seem to misunderstand the define-virtual mechanism. Build pygtk and
look at the generated code to see how it works. Take a look at
examples/gtk/widget.py. There you have an entire widget implemented in
python that overrides virtual methods!

Regards,
  -jkl