Once issue776 is merged, CostAdaptedTask will still use g_root_task but the
usage will no longer be in the constructor but in the parse method of the task
transformation. Getting rid of this is the same problem as getting rid of
g_root_task in the constructor of the search classes (item 2). We currently
cannot replace these easily because our task transformations are not really
transformations, they are tasks themselves.
The current assumption that the task of a heuristic or search engine is known
when it its constructed, is not compatible with general task transformations and
predefined objects. For example, consider a heuristic h with a task
transformation f_h that is nested in two heuristics. If the other heuristics use
transformations f_1 and f_2 then the inner heuristic would have to compute
values for both f_h(f_1(root)) and f_h(f2(root)). This is not possible with our
We discussed this today and plan to move towards code where task transformations
are represented as functions on tasks (mapping tasks to other tasks) and where
we use factories to pass the relevant task to objects like heuristics when they
are used. Once this is done, we can pass g_root_task to SearchEngine::search
which will use the factories to generate the required objects for the given task.
Until then, the search engines remain fixed to g_root_task and the open points
in the summary of this issue will remain open. The use of g_root_task in the
remaining items represents using the task that will eventually be passed through
the factory interface.