Author malte
Recipients florian, jendrik, malte, manuel
Date 2016-01-20.12:08:49
I think there would be a certain logic/consistency in adding such an
initialization method. Path-dependent heuristics need to know about the search
graph as it is being explored. We already have a notification method for the
transitions ("reach_state"), but a notification method for the root is missing.

Let's find a less generic name than "initialize" for this, though. I would see
this as a complement to "reach_state" and suggest that we pick names for these
two that communicate that they have a parallel purpose. For examples, how about
"notify_initial_state" and "notify_state_transition"? We can keep the
reach_state name as an alias for the time being.

This is also related to one of the other big open problems we still have, which
is thinking about what happens if the same component is used in different
contexts, like heuristics that are used in multiple searches. Let's call
plug-ins that support this "sharable plugins". We need to make it clear which
sharing usages the heuristic is supposed to support, and which ones would be
errors. And then we should make sure that the erroneous usages are reported
rather than just leading to corrupt results. If two searches that run in a row
(or concurrently, or in an interleaved fashion) use the same landmark heuristic
object, how should it behave? This affects all heuristics with internal state --
even if it's just the heuristic value cache that all heuristics have.

Do we already have an issue for this? If yes, we should add a link to this
discussion. If not, it would be good to open one. For what it's worth, I feel
uneasy that we use shared_ptr for all new plugin types now because that fails to
communicate that in many cases it's really important that they are *not* shared
with anyone. Perhaps we can use type names like SharablePlugin and
SomethingelsePlugin to make this really clear, and have one of them return
shared_ptr and the other one unique_ptr.
Date User Action Args
2016-01-20 12:08:49maltesetmessageid: <>
2016-01-20 12:08:49maltesetrecipients: + malte, jendrik, florian, manuel
2016-01-20 12:08:49maltelinkissue551 messages
2016-01-20 12:08:49maltecreate