[patch] remove DBusGPendingCall

[Havoc Pennington]

On Wed, 2005-07-06 at 11:06 -0400, Colin Walters wrote:
> On Wed, 2005-07-06 at 01:37 -0400, Havoc Pennington wrote:
> 
> > My basic take on guint IDs in GLib is that they are crackrock - more
> > recent APIs support this view with e.g. GSource* replacing the old ID
> > API.
> 
> Actually as far as I can see GSource * is used when you want to attach
> to non-default mainloops, it doesn't really replace the ID API.
> Functions using GSource still return guint, e.g.:
> 
> guint       g_source_attach                 (GSource *source,
>                                              GMainContext *context);
> 

I think this is basically just back compat noise though. It isn't useful
in any way that I know of.

> However I see your point, and it is a good one.
> 
> The trick GnomeVFS does is to expose what looks like a structure pointer
> in the API, but is actually just a guint internally.  So that's what
> I've done as well.

I generally agree with Ray on the "why?" question ;-) (having the guint
indirection seems like more work/complexity) but sure, as you say we can
clean it up later.

> >  - inefficiency due to the hash table vs. 
> >    just pointer deref
> 
> True, but I'm fairly certain that one hash table lookup is not the
> efficiency bottleneck in the GLib bindings.  I've just been waiting
> until someone complains and identifies specific areas before I work on
> performance.

I doubt this does matter in this case, I'm just making a general point.
I think it matters in the libgobject case unfortunately. All the use of
IDs instead of pointers in libgobject is kind of lame.

> I don't think they do but it should be easy enough to fix.  I think just
> one more conditional in proxy_register.  I'll add this to TODO.

Sounds good.

> Thanks for the comments.  How about this patch?

Yup

Havoc