Introduce few const getters for dom classes

Introduce few const getters for dom classes

and const-ize existing getters where possible. These getters will be used by
TraceWrappables feature coming in in the following cls. As the following cls
will be quite big, I chipped this one out.

LOG=no
BUG=468240

[Marcel Hlopko, 2016-04-12 08:31:26]

hlopko@chromium.org changed reviewers:
+ haraken@chromium.org, jochen@chromium.org

[Marcel Hlopko, 2016-04-12 08:31:27]

Ptal, comments more than welcome :)

[Marcel Hlopko, 2016-04-12 08:33:14]

hlopko@chromium.org changed reviewers:
+ hpayer@chromium.org

[haraken, 2016-04-12 08:35:59]

Would you elaborate on why you need to add these const getters?

[Marcel Hlopko, 2016-04-12 09:55:35]

Sure (and if you'd prefer that, I can upload them together with the following cl
which actually uses them).

So in the following cl, I will introduce ScriptWrappableVisitor, which will
trace through script wrappables, exactly as you described in the design doc.
ScriptWrappables will implement traceWrappable(ScriptWrappableVisitor*) method.
Most of these methods are straightforward and will be generated from idl files
using TraceWrappableReferences=(firstChild,parent,...). firstChild and parent
are getters which will be called from the generated code. I chose getters,
because raw access into some fields is problematic (Node.rareData for example).

Some of the new getters (mainly maybeXXX ones) I introduced because getters
already present were lazy-initializing stuff. We don't neither need nor want to
do that during tracing.

Now why do we need getters to be const, two reasons. First, again, to be sure we
don't do expensive or useless initialization in the getters. And second,
Document.m_nodeLists is HeapHashSet<WeakMember<const LiveNodeListBase>>. I need
to visit those lists. I could remove const, or make visiting const. I decided
not to remove the const from here and made visiting const instead (because I
liked the first point). And when visiting is const, EventListenerIterator and
EventTargetData related code have to be too. Does this make any sense to you? :)

[haraken, 2016-04-12 11:20:32]

On 2016/04/12 09:55:35, Marcel Hlopko wrote:
> Sure (and if you'd prefer that, I can upload them together with the following
cl
> which actually uses them).
> 
> So in the following cl, I will introduce ScriptWrappableVisitor, which will
> trace through script wrappables, exactly as you described in the design doc.
> ScriptWrappables will implement traceWrappable(ScriptWrappableVisitor*)
method.
> Most of these methods are straightforward and will be generated from idl files
> using TraceWrappableReferences=(firstChild,parent,...). firstChild and parent
> are getters which will be called from the generated code. I chose getters,
> because raw access into some fields is problematic (Node.rareData for
example).
> 
> Some of the new getters (mainly maybeXXX ones) I introduced because getters
> already present were lazy-initializing stuff. We don't neither need nor want
to
> do that during tracing.
> 
> Now why do we need getters to be const, two reasons. First, again, to be sure
we
> don't do expensive or useless initialization in the getters. And second,
> Document.m_nodeLists is HeapHashSet<WeakMember<const LiveNodeListBase>>. I
need
> to visit those lists. I could remove const, or make visiting const. I decided
> not to remove the const from here and made visiting const instead (because I
> liked the first point). And when visiting is const, EventListenerIterator and
> EventTargetData related code have to be too. Does this make any sense to you?
:)

Thanks for the clarification, Marcel!

Yeah, maybe I want to look at the entire CL. I'm not quite sure if it's a good
idea to generate the tracing code. I was thinking that the tracing code will
anyway require a lot of customized logic, so it would be simpler to just ask
people to hand-write the contents of the tracing method (rather than asking
people to write const getters required by the auto-generated tracing code) like
this:

void Node::traceWrapper(ScriptWrappableVisitor* visitor) {
  visitor->trace(m_firstChild);
  visitor->trace(m_parentNode);
  ...;
}

But I'm not sure :)

[Marcel Hlopko, 2016-04-12 11:43:53]

So let's keep this cl hanging, and continue discussion over in the
https://codereview.chromium.org/1876383003, which can be landed independently of
this one. Once we polish the details, I will revisit this cl and maybe delete
it.