[webkit-dev] Moving code from Element to NamedNodeMap -- I think that is the wrong direction

[Darin Adler]

Hi folks.

One of the main things the Element class does is implement an attribute store for elements. Currently, this attribute store is in a separate reference-counted object. That object is exposed to the DOM as NamedNodeMap.

But I believe this is not a good pattern for the long run. The reason that separate object exists with a reference count on it is that it is exposed as part of the DOM API, to provide something we can return from the attributes function. We don’t want our in-memory implementation of elements to be tied to the fact that occasionally a client might want access to the reference counted map.

A much better factoring is to turn NamedNodeMap into a wrapper for the Element. The actual attribute mapping should be elsewhere. Either in Element itself, or some other helper class.

I’ve seen patches moving more of the attribute logic to NamedNodeMap, and I am concerned that this is not a step in the right direction.

One of the first things we should do is to remove the separate reference count stored in each NamedNodeMap. That can be done immediately by using OwnPtr instead of RefPtr to hold it on each Element, and changing the ref and deref functions to simply ref and deref the owning element instead of the map itself.

But longer term we want to get rid of other unneeded overhead. For example, the back pointer from the heap-allocated vector of attributes to the element is a waste of space. To do that, I think we want to implement NamedNodeMap.idl on a class that does nothing but pass the calls through.

-- Darin