RESOLVED FIXED 150347
Use tighter typing for collections / node lists' item() / namedItem() methods
https://bugs.webkit.org/show_bug.cgi?id=150347
Summary Use tighter typing for collections / node lists' item() / namedItem() methods
Chris Dumez
Reported 2015-10-19 16:50:52 PDT
Use tighter typing for collections / node lists' item() / namedItem() methods
Attachments
Patch (26.37 KB, patch)
2015-10-19 18:39 PDT, Chris Dumez
no flags
Patch (26.25 KB, patch)
2015-10-20 11:01 PDT, Chris Dumez
no flags
Chris Dumez
Comment 1 2015-10-19 18:39:28 PDT
Darin Adler
Comment 2 2015-10-20 08:57:45 PDT
Comment on attachment 263540 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=263540&action=review More elegant; seems good. A little sad to have to remove the final from some of the item functions, just so we can narrow the type in a derived class. We don’t gain anything by calling the derived class’s override when calling the function on the base class at runtime except maybe an assertion in debug builds. But I can’t think of a simple alternative. These function bodies are messy enough that I would prefer to see them after the classes rather than inside the class definitions. > Source/WebCore/accessibility/AccessibilityRenderObject.cpp:1783 > + for (unsigned i = 0; auto* current = links->item(i); ++i) { Would be nice to eventually come up with a cleaner idiom for iterating an HTMLCollection in C++ code. We could probably make begin/end and iterators to make this work with a modern for loop. > Source/WebCore/accessibility/AccessibilityRenderObject.cpp:1786 > + RefPtr<AccessibilityObject> axObject = document.axObjectCache()->getOrCreate(renderer); > + ASSERT(axObject); Makes me wonder why getOrCreate doesn’t return a Ref. > Source/WebCore/html/HTMLSelectElement.cpp:458 > + before = options()->item(index + 1); Seems like we could call our own item() here rather than explicitly calling options()->item(). > Source/WebCore/html/HTMLTableRowElement.cpp:136 > - RefPtr<Node> cell = children->item(index); > + RefPtr<Element> cell = children->item(index); I suggest removing this local variable entirely so we don’t have to state the type. > Source/WebCore/html/HTMLTableSectionElement.cpp:91 > - RefPtr<Node> row = children->item(index); > + RefPtr<Element> row = children->item(index); I suggest removing this local variable entirely so we don’t have to state the type. > Source/WebCore/html/RadioNodeList.h:46 > + HTMLElement* item(unsigned offset) const override { return downcast<HTMLElement>(CachedLiveNodeList<RadioNodeList>::item(offset)); } > + > + virtual ~RadioNodeList(); I think the override should come after the destructor, not before.
Chris Dumez
Comment 3 2015-10-20 10:25:34 PDT
Comment on attachment 263540 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=263540&action=review >> Source/WebCore/accessibility/AccessibilityRenderObject.cpp:1783 >> + for (unsigned i = 0; auto* current = links->item(i); ++i) { > > Would be nice to eventually come up with a cleaner idiom for iterating an HTMLCollection in C++ code. We could probably make begin/end and iterators to make this work with a modern for loop. Agreed. >> Source/WebCore/html/HTMLSelectElement.cpp:458 >> + before = options()->item(index + 1); > > Seems like we could call our own item() here rather than explicitly calling options()->item(). Ok. >> Source/WebCore/html/HTMLTableRowElement.cpp:136 >> + RefPtr<Element> cell = children->item(index); > > I suggest removing this local variable entirely so we don’t have to state the type. Ok >> Source/WebCore/html/HTMLTableSectionElement.cpp:91 >> + RefPtr<Element> row = children->item(index); > > I suggest removing this local variable entirely so we don’t have to state the type. Ok. >> Source/WebCore/html/RadioNodeList.h:46 >> + virtual ~RadioNodeList(); > > I think the override should come after the destructor, not before. Ok.
Chris Dumez
Comment 4 2015-10-20 11:01:03 PDT
WebKit Commit Bot
Comment 5 2015-10-20 11:49:07 PDT
Comment on attachment 263592 [details] Patch Clearing flags on attachment: 263592 Committed r191351: <http://trac.webkit.org/changeset/191351>
WebKit Commit Bot
Comment 6 2015-10-20 11:49:13 PDT
All reviewed patches have been landed. Closing bug.
Simon Fraser (smfr)
Comment 7 2015-10-20 13:37:51 PDT
This broke EFL: DerivedSources/webkitdom/WebKitDOMHTMLFormElement.cpp:31:56: fatal error: WebKitDOMHTMLFormControlsCollectionPrivate.h: No such file or directory #include "WebKitDOMHTMLFormControlsCollectionPrivate.h"
Note You need to log in before you can comment on or make changes to this bug.