|
Size: 1340
Comment:
|
Size: 2282
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 10: | Line 10: |
| * Objects created by plug-ins: what should they be called? When do we need a factory, and when does the plug-in generate the object directly? How is their lifetime managed -- when should we use shared_ptr and when should we use raw pointer? | |
| Line 15: | Line 14: |
| Line 21: | Line 21: |
= Items with action plans = == Component creation and interaction == Objects created by plug-ins: what should they be called? When do we need a factory, and when does the plug-in generate the object directly? How is their lifetime managed -- when should we use shared_ptr and when should we use raw pointer? Terminology: * component: e.g. {{{FFHeuristic}}}, {{{AlternationOpenList}}}, {{{LandmarkFactorySasp}}} * component builder: stores options and creates components * plugin: creates a component builder, interacts with option parser Action plan: * Use classes for plugins instead of {{{_parse}}} functions. * Plugin classes allow adding commandline options, call {{{OptionParser::parse()}}}, create component builders (and pass the Options object to their constructor). * Optional: if needed a common plugin base class could handle things like {{{dry_run()}}} * Component builders store the options. When invoked they create a component. * Optional: component builders could unpack the options. Then the components would not need to know anything about option parsing. We decided to leave this as is in the first step to avoid code churn. |
Back to ForDevelopers.
Long term plans
use task interface everywhere (issue509)
remove preprocessor (issue26)
state representation (issue401)
life-time management of shared objects (e.g. CG) (related: issue564)
- rethink which shared objects can go together (e.g. when is it OK for a heuristic to use a different task than a search algorithm using it? When is it OK for a pattern selector to work with a different task? a landmark factory? an operator-counting constraint generator? etc.)
plugins for open lists (issue610)
- remove global objects
group code into namespaces and core (issue64)
new plugin types without code changes in option parser (issue588)
Needs tender love and care
- landmarks
- option parser
- search
Items with action plans
Component creation and interaction
Objects created by plug-ins: what should they be called? When do we need a factory, and when does the plug-in generate the object directly? How is their lifetime managed -- when should we use shared_ptr and when should we use raw pointer?
Terminology:
component: e.g. FFHeuristic, AlternationOpenList, LandmarkFactorySasp
- component builder: stores options and creates components
- plugin: creates a component builder, interacts with option parser
Action plan:
Use classes for plugins instead of _parse functions.
Plugin classes allow adding commandline options, call OptionParser::parse(), create component builders (and pass the Options object to their constructor).
Optional: if needed a common plugin base class could handle things like dry_run()
- Component builders store the options. When invoked they create a component.
- Optional: component builders could unpack the options. Then the components would not need to know anything about option parsing. We decided to leave this as is in the first step to avoid code churn.