I can very much relate to many statements in Malte's msg11227. For example, it sometimes already feels to me like if we're treating some parts of the code like independent libraries; I'm not super familiar but I believe there's little interaction between the Cartesian abstraction code and the PDB code, even though they both deal with abstractions and are hence somewhat closely related. More importantly, there are certainly parts that are completely independent and maintained mostly by different sets of people. It might also render our processes easier if the separation is clearer in the code. Speaking of which, as a student I was overwhelmed when I worked with Fast Downward for the first time. It turned out to be not too hard to get started, but by breaking up the planner into smaller modules, it might become easier to gain an overview of the relevant parts for working on a specific project/thesis.

On another note: Grouping the namespaces by category type (e.g., same namespace for all evaluators) seems a bit odd to me because it is kind of repeating the structure provided by abstract interfaces or inheritance, isn't it? These already bind those pieces together logically, so it seems redundant to also group them in the same namespace. But maybe there's something I'm missing here that goes beyond signaling pieces that serve similar purposes and share certain dependencies.

If you are collecting a wish list of renames, I'd like to add
* operatorcounting -> operator_counting
* lpsolver -> lp_solver
  (or maybe mip_solver, since we now support integer variables)

Generally, it would be nice to make the use of underscores more consistent.

Mention namespace thing in issue title.

I'd rephrase part of the discussion a little bit: we want to discuss whether we want different namespaces or not; we haven't decided yet if we want this. The reason we don't currently have them isn't really that we didn't want to implement them but that we don't know if we want them.


The balance of the discussion shifts a little bit with the Python interface and the idea that different Fast Downward components could be contributed by different libraries. For example, in that context it might make sense to have a "one namespace per library" rule.

This then prompts the question if some parts of the current Fast Downward code should logically be libraries separated from the core, which then interacts with the discussion recently opened by Clemens about having deeper nesting of namespaces. If we want multiple-levels deep nesting, perhaps this is one indication that something wants to be its own library.

I think in a Python-style library you would want separation into multiple namespaces because it makes things less cluttered, less likely to collide if you use code from different people, and you always have the option of "from xxx import *" if that's what you want.

For the command line however, as we discussed, you probably don't want to use dotted names everywhere, and I think this is currently the strongest argument against this. Perhaps a simple answer to this is for the command-line version of Fast Downward to do the equivalent of "from xxx import *" for some modules by default.


On the balance, now that I've assembled my thoughts a bit more, I think I would indeed prefer to have (the option of) separate namespaces, one of which could be "core" (or some such), and that the namespaces should *not* be grouped by category type (like we discussed later), as in one namespace for all evaluators, one for all merge scoring functions etc., but that the grouping should be by which larger "package" we associate the code with. For example, we could have one "merge_and_shrink" package with all our current stuff, which would provide one evaluator, multiple scoring functions, etc. This seems to be an almost unavoidable direction to go if in the long term we want to properly support the model of people contributing their own components independently as libraries.

When discussing renaming directories in issue1098 and issue1099, we also agreed that it would be nice to make the names of features (i.e., their identifier used on the command line) consistent in Fast Downward. There are many features that use generic names which are not easily associated with the namespace they belong to (e.g., "total_order" for a M&S scoring function, "manual" for a pattern generator, or "max" for the maximum combination of two evaluators). Also, some heuristics use the word "heuristic" in their name, others don't. Ideally, we would like to have something like namespaces also for our feature names, so that we can use the same feature name in different places. If that doesn't work, using a clear pattern such a prefixing names could be an option, too.