[Bug 21097] proxy subclasses should support optional features

[bugzilla-daemon at freedesktop.org]

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

--- Comment #11 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> 2010-04-06 10:01:51 PDT ---
> You did mis-parse, but I agree it could be clearer. The intended meaning was
> "This is a less general form of t_p_i_p(); t_p_i_p() should be used in new
> code", but I think that's an unwieldy way to phrase it.
> 
> Perhaps "New code should use t_p_i_p(), which is a more general form of this
> method"?

Yeah I prefer this phrasing.

> > I guess it's ok to call tp_cli_connection_call_connect on a not prepared
> > TpConnection right?
> 
> Yes, the TpConnection already knows that it's a Connection.
> 
> > Shouldn't we deprecate old API?
> 
> Not yet, I don't think; deprecation is rather a big stick (it breaks all of our
> development builds, because they have -Werror and -Wdeprecated-declarations),
> and we probably shouldn't deprecate API for which the replacement requires a
> bleeding-edge dependency. I'd be inclined to deprecate the call_when_ready
> family in 0.13.0.
> 
> It's an unfortunate situation... I'd like to have a way to get non-fatal
> warnings for things that aren't yet fully deprecated, but are on the way there
> (like tp_get_bus(), premature deprecation of which broke the buildbot today).

I'm not sure. Depreacting API is not that bad, you can still easily remove the
deprecated flag if needed and it's useful to spot code using the old API.
AFAIK, GTK+ deprecated API as soon there is a replacement for them and that
works fine.

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