Merge NamedNodesCollection and StaticNodeList classes

Merge NamedNodesCollection and StaticNodeList classes

Merge NamedNodesCollection and StaticNodeList classes into a single
StaticNodeTypeList templated class as these are identical besides the type
of Node they hold. NamedNodesCollection was holding Elements so it is now
named StaticElementList which is a typedef to StaticNodeTypeList<Element>.
StaticNodeList holds Node and is now a typedef to StaticNodeTypeList<Node>.

This avoids code duplication and allows for tighter typing when using a
StaticNodeList. As a side effect, memory used by StaticElementList (formely
NamedNodesCollection is now reported to V8 as StaticNodeList code was doing
so).

R=adamk@chromium.org, jochen@chromium.org

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=180084

[adamk, 2014-08-11 22:48:58]

This lgtm, but I do notice that the two uses of NamedNodeCollection don't really
care much that the NodeList they're creating contains Elements (and both,
actually, have FIXMEs that say we shoudn't be using NodeLists). More type safety
seems nice, though. Hopefully this doesn't bloat binary size much?

[Inactive, 2014-08-11 23:28:36]

On 2014/08/11 22:48:58, adamk wrote:
> This lgtm, but I do notice that the two uses of NamedNodeCollection don't
really
> care much that the NodeList they're creating contains Elements (and both,
> actually, have FIXMEs that say we shoudn't be using NodeLists). More type
safety
> seems nice, though. Hopefully this doesn't bloat binary size much?

Yes, tighter typing is nice, especially in the SelectorQuery case. I will verify
the binary size impact tomorrow.

[Inactive, 2014-08-12 13:23:58]

On 2014/08/11 22:48:58, adamk wrote:
> This lgtm, but I do notice that the two uses of NamedNodeCollection don't
really
> care much that the NodeList they're creating contains Elements (and both,
> actually, have FIXMEs that say we shoudn't be using NodeLists). More type
safety
> seems nice, though. Hopefully this doesn't bloat binary size much?

There is a 4Kb size increase on the stripped release binary. What do you think?

For the record, another reason (besides tighter typing) why I made
StaticNodeList templated is because call sites that used to create a
NamedNodesCollection have a Vector<RefPtr<Element>> instead of a
Vector<RefPtr<Node>> and one cannot be implicitly converted in the other.

[jochen (gone - plz use gerrit), 2014-08-12 14:47:57]

lgtm

[adamk, 2014-08-12 16:46:04]

On 2014/08/12 at 13:23:58, ch.dumez wrote:
> On 2014/08/11 22:48:58, adamk wrote:
> > This lgtm, but I do notice that the two uses of NamedNodeCollection don't
really
> > care much that the NodeList they're creating contains Elements (and both,
> > actually, have FIXMEs that say we shoudn't be using NodeLists). More type
safety
> > seems nice, though. Hopefully this doesn't bloat binary size much?
> 
> There is a 4Kb size increase on the stripped release binary. What do you
think?

Still lgtm. 

> For the record, another reason (besides tighter typing) why I made
StaticNodeList templated is because call sites that used to create a
NamedNodesCollection have a Vector<RefPtr<Element>> instead of a
Vector<RefPtr<Node>> and one cannot be implicitly converted in the other.

Yeah, I noticed that too on second reading.

[Inactive, 2014-08-12 16:51:26]

The CQ bit was checked by ch.dumez@samsung.com

[commit-bot: I haz the power, 2014-08-12 16:52:29]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/ch.dumez@samsung.com/465483002/20001

[haraken, 2014-08-12 16:53:19]

LGTM. I think 4KB would be acceptable. The benefit of cleaning up the code base
would be a win.

[commit-bot: I haz the power, 2014-08-12 16:57:06]

Change committed as 180084