RESOLVED FIXED 164206
Move Element, NamedNodeMap, and DOMStringMap from ExceptionCode to Exception
https://bugs.webkit.org/show_bug.cgi?id=164206
Summary Move Element, NamedNodeMap, and DOMStringMap from ExceptionCode to Exception
Darin Adler
Reported 2016-10-30 09:09:14 PDT
Move Element, NamedNodeMap, and DOMStringMap from ExceptionCode to Exception
Attachments
Patch (102.26 KB, patch)
2016-10-30 10:02 PDT, Darin Adler
no flags
Patch (104.18 KB, patch)
2016-10-30 12:33 PDT, Darin Adler
no flags
Patch (104.96 KB, patch)
2016-10-30 15:13 PDT, Darin Adler
no flags
Patch (105.24 KB, patch)
2016-10-30 15:21 PDT, Darin Adler
no flags
Patch (105.23 KB, patch)
2016-10-30 15:28 PDT, Darin Adler
no flags
Darin Adler
Comment 1 2016-10-30 10:02:31 PDT
Chris Dumez
Comment 2 2016-10-30 11:54:11 PDT
Comment on attachment 293351 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=293351&action=review r=me but looks like GTK / Win are possibly broken. > Source/WebCore/ChangeLog:12 > + true any time an exception is raised. Since true tealls the caller to return "tells" > Source/WebCore/ChangeLog:26 > + removeAttributeNode. Changed to use is<Document> and is<Attr> instead of Why is this better for performance? The common case is likely an Element. For an Element, we used to do a single virtual function call (nodeType()), and now we have 2 branches: - isDocumentNode() which is non-virtual - isAttributeNode() which is virtual It looks to me that only adopting a Document became a bit faster but this is likely not a common case. > Source/WebCore/dom/DatasetDOMStringMap.cpp:196 > +ExceptionOr<void> DatasetDOMStringMap::setItem(const String& name, const String& value) const I don't feel strongly but I personally feel making such setters const is a bit confusing. I read your explanation in the Changelog but even so. > Source/WebCore/inspector/InspectorDOMAgent.cpp:669 > + auto result = parsedElement.get().setInnerHTML("<span " + text + "></span>"); don't we usually use parsedElement->setInnerHTML() ?
Darin Adler
Comment 3 2016-10-30 12:21:08 PDT
Comment on attachment 293351 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=293351&action=review >> Source/WebCore/ChangeLog:26 >> + removeAttributeNode. Changed to use is<Document> and is<Attr> instead of > > Why is this better for performance? The common case is likely an Element. For an Element, we used to do a single virtual function call (nodeType()), and now we have 2 branches: > - isDocumentNode() which is non-virtual > - isAttributeNode() which is virtual > > It looks to me that only adopting a Document became a bit faster but this is likely not a common case. Good point, I will change it back. I did not realize that isAttributeNode was virtual. >> Source/WebCore/dom/DatasetDOMStringMap.cpp:196 >> +ExceptionOr<void> DatasetDOMStringMap::setItem(const String& name, const String& value) const > > I don't feel strongly but I personally feel making such setters const is a bit confusing. I read your explanation in the Changelog but even so. I’m going to leave it this way. I agree there are arguments both ways. I think it’s better for these wrappers to be more true to their status as wrappers and not pretend they actually contain the data, but we could go the other direction too I suppose and try to do "transitive const-ness". >> Source/WebCore/inspector/InspectorDOMAgent.cpp:669 >> + auto result = parsedElement.get().setInnerHTML("<span " + text + "></span>"); > > don't we usually use parsedElement->setInnerHTML() ? The advantage of .get(). over -> is that it doesn’t look like a pointer dereference. I’m not sure we have standardized either way. Kling suggested that we prefer .get(). but we didn’t really firm this up.
Darin Adler
Comment 4 2016-10-30 12:29:03 PDT
Comment on attachment 293351 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=293351&action=review >>> Source/WebCore/dom/DatasetDOMStringMap.cpp:196 >>> +ExceptionOr<void> DatasetDOMStringMap::setItem(const String& name, const String& value) const >> >> I don't feel strongly but I personally feel making such setters const is a bit confusing. I read your explanation in the Changelog but even so. > > I’m going to leave it this way. I agree there are arguments both ways. I think it’s better for these wrappers to be more true to their status as wrappers and not pretend they actually contain the data, but we could go the other direction too I suppose and try to do "transitive const-ness". No, changed my mind. I’ll do it the other way.
Darin Adler
Comment 5 2016-10-30 12:33:03 PDT
Darin Adler
Comment 6 2016-10-30 15:13:19 PDT
Darin Adler
Comment 7 2016-10-30 15:21:28 PDT
Darin Adler
Comment 8 2016-10-30 15:28:27 PDT
Darin Adler
Comment 9 2016-10-30 15:39:02 PDT
Note You need to log in before you can comment on or make changes to this bug.