[Bug 26059] Requests Mixin doesn't create Handles on demand

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=26059

--- Comment #3 from Ed Page <eopage at byu.net> 2010-04-16 15:58:44 PDT ---
(In reply to comment #2)
> Why did you implement get_handle_by_name?

I actually use get_handle_by_name in several parts of The One Ring.
1. When i need a single item its nicer to get it than handle the list case
2. I imagine CMs would not normally specialize the boilerplate in
RequestHandles but just what is exactly in get_handle_by_name
3. Maybe its a lack of knowledge in how the dbus bindings work but I feel weird
internally calling into the external API
4. I'm not too sure what all cases handles should be marked as client handles
but its nicer to have a call under the hood for when a handle isn't a client
handle

> Why not just use RequestHandles and
> require that it returns Handle objects (or subclasses). The problem I foresee
> here is that butterfly expects all its handles to be of type ButterflyHandle.
> This works because it re-implements RequestHandles. What we could do is
> something like this:
> -            ret.append(handle.get_id())
> +            ret.append(handle)
> 
> in RequestHandles, and add a __int__() method to telepathy.server.Handle which
> returns the same as get_id(). What do you think? It sounds like a cleaner
> solution and nicer to CMs using tp-python (we've got to give them something!)
> 
> This solution would also mean that bug #27445 could be fixed in tp-python
> instead of butterfly which is cool. Thoughts?

I think this change makes sense independent of whether get_handle_by_name is
used or not.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.