[Webkit-unassigned] [Bug 26726] [Gtk] hide deprecated functions when WEBKIT_GTK_DISABLE_DEPRECATED is defined

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=26726


Daniel Macks <dmacks at netspace.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dmacks at netspace.org




--- Comment #2 from Daniel Macks <dmacks at netspace.org>  2009-07-10 08:18:19 PDT ---
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).

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