It would be cool if it was possible to hide deprecated stuff to keep your code up-to-date. Hiding the API when a define is set (like GLib and GTK+ do) sounds like a good way to do it.
(In reply to comment #0) > It would be cool if it was possible to hide deprecated stuff to keep your code > up-to-date. Hiding the API when a define is set (like GLib and GTK+ do) sounds > like a good way to do it. > We should be using WEBKIT_OBSOLETE_API or for these functions but I don't think it's being used right now.
webkitwebframe.h uses WEBKIT_DISABLE_DEPRECATED to shield some deprecated stuff (hiding the prototypes in the .h) OTOH, webkitdefines.h gives a WEBKIT_OBSOLETE_API macro to use to tag deprecated symbols with an __attribute__. However, nothing it tagged with it (as of 1.1.10 release). Seems un-necessarily confusing for coders to have two different ways to mark the old cruft and for users to have two different behaviors associated with use of old cruft. WEBKIT_DISABLE_DEPRECATED follows the standard naming pattern used in the gnome core packages for this purpose (GTK_DISABLE_DEPRECATED for deprecated stuff in libgtk, etc.). It's also the same behavior for these tokens: if pkg has a #define (or more often a -D) for this token and uses a tagged function, it's a compiler error, otherwise it's silently used. WEBKIT_OBSOLETE_API (which I agree does not appear to be used anywhere in 1.1.10) behaves differently: if a pkg uses a tagged function, it defaults to being a compiler warning, but can be hidden by using -Wno-deprecated-declarations. The latter seems less portable: __attribute__((deprecated)) is apparently not available on win32 (or at least webkitdefines.h totally disables this mechanism on win32. It's also more in-your-face/highly visible compiler noise for end-users who are just trying to use an upstream source release (vs *_DISABLE_DEPRECATED that can be enabled in maintainer-mode only, for example).
I don't think we have deprecated API any longer.