Bug 26726
| Summary: | [Gtk] hide deprecated functions when WEBKIT_GTK_DISABLE_DEPRECATED is defined | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Emilio Pozuelo Monfort <pochu27> |
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Enhancement | CC: | dmacks, jmalonzo, mrobinson |
| Priority: | P2 | Keywords: | Gtk |
| Version: | 528+ (Nightly build) | ||
| Hardware: | PC | ||
| OS: | Linux | ||
Emilio Pozuelo Monfort
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Jan Alonzo
(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.
Daniel Macks
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).
Martin Robinson
I don't think we have deprecated API any longer.