Bug 133728 – [GTK] Remove all deprecated API from GObject DOM bindings

• Component: Bindings
• Status: RESOLVED FIXED

[Carlos Garcia Campos]

And all the exceptions in the code generator because of the deprecated stuff.

[Carlos Garcia Campos]

Created attachment 232942 [details]
Patch

[WebKit Commit Bot]

Attachment 232942 [details] did not pass style-queue:


ERROR: Tools/gtk/webkitdom.py:30:  multiple statements on one line (semicolon)  [pep8/E702] [5]
Total errors found: 1 in 7 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Martin Robinson]

Comment on attachment 232942 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=232942&action=review

> Tools/gtk/webkitdom.py:30
> +    DELETED_CLASSES = [];

I think it's worth getting rid of write_deleted_classes now altogether. We should just try to make sure to not break API in the future.

[Carlos Garcia Campos]

(In reply to comment #3)
> (From update of attachment 232942 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=232942&action=review
> 
> > Tools/gtk/webkitdom.py:30
> > +    DELETED_CLASSES = [];
> 
> I think it's worth getting rid of write_deleted_classes now altogether. We should just try to make sure to not break API in the future.

We have never broken the API on purpose, idl files change and we can't control that. So, I prefer to keep all the deprecation machinery for the future.

[Carlos Garcia Campos]

The build break is because a clean build is required

[Martin Robinson]

Comment on attachment 232942 [details]
Patch

I'm not wild about the dead code. I really think we should also just stop generating "unstable" API to prevent API breaks in the future, so that we can remove this code without worrying. Please at least consider this path.

[Carlos Garcia Campos]

(In reply to comment #6)
> (From update of attachment 232942 [details])
> I'm not wild about the dead code. I really think we should also just stop generating "unstable" API to prevent API breaks in the future, so that we can remove this code without worrying. Please at least consider this path.

Thanks for the review. Ok, I'll remove the dead code, but it will be  pain to bring all that back from history if we need it again eventually. If we have users using unstable API, in the worst case, they will just need to add an include header and define a macro, and then recompile. Note that changes in the unstable API are not API breaks, so we don't need to worry about them.

[Carlos Garcia Campos]

Committed r169931: <http://trac.webkit.org/changeset/169931>