RESOLVED FIXED Bug 51863
[chromium] WEBKIT_API and styling fixes for the chromium api.
https://bugs.webkit.org/show_bug.cgi?id=51863
Summary [chromium] WEBKIT_API and styling fixes for the chromium api.
David Levin
Reported 2011-01-03 18:57:48 PST
Attachments
Patch (10.76 KB, patch)
2011-01-03 19:01 PST, David Levin
no flags
Patch (10.13 KB, patch)
2011-01-04 14:05 PST, David Levin
no flags
David Levin
Comment 1 2011-01-03 19:01:34 PST
Eric Seidel (no email)
Comment 2 2011-01-03 23:40:30 PST
Comment on attachment 77864 [details] Patch These look right to me.
Darin Fisher (:fishd, Google)
Comment 3 2011-01-04 00:57:51 PST
Comment on attachment 77864 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=77864&action=review > WebKit/chromium/public/WebDOMEventListener.h:51 > + virtual ~WebDOMEventListener(); this will break the build. because the implementation is provided by a .cpp file and callable by chromium, it needs to be marked WEBKIT_API. it is rather unusual for us to have virtual destructors in the API like this. the destructor needs to be virtual because this is an interface meant to be subclassed. to keep the rules simple, we could just have this be implemented inline to a private method, and then that private method would be marked WEBKIT_API.
David Levin
Comment 4 2011-01-04 07:10:57 PST
(In reply to comment #3) > (From update of attachment 77864 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=77864&action=review > > > WebKit/chromium/public/WebDOMEventListener.h:51 > > + virtual ~WebDOMEventListener(); > > this will break the build. because the implementation is provided by > a .cpp file and callable by chromium, it needs to be marked WEBKIT_API. > > it is rather unusual for us to have virtual destructors in the API like > this. the destructor needs to be virtual because this is an interface > meant to be subclassed. to keep the rules simple, we could just have > this be implemented inline to a private method, and then that private > method would be marked WEBKIT_API. According to https://lists.webkit.org/pipermail/webkit-dev/2010-December/015188.html, virtual functions should not have WEBKIT_API. Why doesn't that apply in this case?
David Levin
Comment 5 2011-01-04 07:21:55 PST
(In reply to comment #4) > (In reply to comment #3) > > (From update of attachment 77864 [details] [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=77864&action=review > > > > > WebKit/chromium/public/WebDOMEventListener.h:51 > > > + virtual ~WebDOMEventListener(); > > > > this will break the build. because the implementation is provided by > > a .cpp file and callable by chromium, it needs to be marked WEBKIT_API. > > > > it is rather unusual for us to have virtual destructors in the API like > > this. the destructor needs to be virtual because this is an interface > > meant to be subclassed. to keep the rules simple, we could just have > > this be implemented inline to a private method, and then that private > > method would be marked WEBKIT_API. > > According to https://lists.webkit.org/pipermail/webkit-dev/2010-December/015188.html, virtual functions should not have WEBKIT_API. Why doesn't that apply in this case? Perhaps this is it: virtual functions should have WEBKIT_API if a derived implementation may be implemented outside of WebKit, and it may want to call the base implementation and that is the case for WebDOMEventListener?
Darin Fisher (:fishd, Google)
Comment 6 2011-01-04 09:53:59 PST
(In reply to comment #4) > According to https://lists.webkit.org/pipermail/webkit-dev/2010-December/015188.html, virtual functions should not have WEBKIT_API. Why doesn't that apply in this case? Sorry, my expectation when writing that rule was that all virtual functions would have inline implementations. It is a rare case that they do not. To make the rules easier to follow, how about we make the virtual ~WebDOMEventListener have an inline implementation that calls a private WEBKIT_API method, named 'reset' and similarly have the constructor call an 'initialize' method. The constructor should null out m_private before calling initialize.
David Levin
Comment 7 2011-01-04 14:05:06 PST
WebKit Commit Bot
Comment 8 2011-01-05 14:20:55 PST
Comment on attachment 77927 [details] Patch Clearing flags on attachment: 77927 Committed r75106: <http://trac.webkit.org/changeset/75106>
WebKit Commit Bot
Comment 9 2011-01-05 14:21:02 PST
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.