James Henstridge writes:
> Well, this is one of those things where we won't know how many useful non
> gui libraries will use the object model until after the glib/gtk 2.0
> release. I have decided to put the GObject wrapper stuff in a separate
> module just in case.
There's certainly no way to be completely sure. My comment was
intended to mean something more along the lines of "I have no idea how
much typical C programmers are trying to emulate 'object' behavior,"
especially since the GKT+ approach is relatively heavyweight,
providing a substantial classing mechanism. Most of the object-like
uses of C I've seen haven't had any support for class relationships;
those that have have been language implementations. ;)
Making this a separate module makes a lot of sense as way to avoid
re-engineering at a later point.
> For quite a while, I have been passing function pointers around as
> CObjects in the modules (eg. gtk._gtk._PyGtk_API in the 0.7.0 release),
> which means that the different wrapper modules don't need to see each
> other's symbols.
Excellent! The example of using a CObject as an API container/
accessor made this look very tedious for the implementor; what can I
do to make this easier to use?
> As for symbols from libraries, I think from python 1.5.2, it doesn't use
> the RTLD_GLOBAL flag when loading extensions, so the extensions don't
> pollute the global symbol table.
Yes, I understand why, I just recall having lots of problems with
the Imlib stuff because of that. That was a year ago, so has probably
been fixed at this point, but I must admit that I've not built any of
this stuff for a while now.
> What would be nice would be if ExtensionClass integrated better with
> python (so that all the special cases for normal classes work for
> ExtensionClasses).
I'd be very interested in your comments on what it would take to
make things easier if something like ExtensionClass were available as
part of the core, both from the requirements side and ease-of-use
perspective.
-Fred
--
Fred L. Drake, Jr. <fdrake at beopen.com>
BeOpen PythonLabs Team Member
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
