dynamobi/dynamobi — Issue #459: [FNL-49] come up with a solution for reliable TraceSource initialization
Author: dynamobi-build
Created: 2011-12-30 03:27:51+00:00
State: open
Labels: Common, FNL

[reporter="jvs", created="Thu, 10 Aug 2006 17:23:31 -0500 (GMT-05:00)"]
We use virtual inheritance for TraceSource in many places. The fact that it has a default constructor makes this into a major gotcha, because if the most-derived class does not explicitly call the constructor, and instead passes the parameters up to the superclass, the default constructor gets called instead (so no tracing gets enabled). This is currently the case for DfsTreeExecStreamScheduler; Zelaine is going to fix it.

Seems like the problem results from the fact that sometimes we want to initialize TraceSources at construction time (e.g. ExecStreamScheduler), and sometimes we want to initialize them afterwards (e.g. ExecStreams, where we definitely don't want to take constructor parameters).

One solution would be to get rid of the TraceSource constructor which takes parameters, and require TraceSource initialization to always be done via a call to initTraceSource.

Another one would be to introduce a new subclass UninitializedTraceSource (need a better name) and move the default constructor there. Then anyone inheriting TraceSource directly would be forced by the compiler to make the constructor call from all levels; classes like ExecStreams would inherit UninitializedTraceSource instead, so they wouldn't need to make any constructor call.