Based on PR #445 :
Now since we already have a clearly articulated input / output behavior, and one version of workflows of ASAPPlanner, can we materialize this logical picture to concrete lib functions visible to lib / cli users?
This means, we only expose to users what we conceptually described in the input / output and workload document, and all other internal steps are kept invisible to outside.
This will help future development by making iterating certain logical component much easier, since we only need replacing instead of appending.
Notice:
There's still some pending discussion on the specific content of input-output and workflow in #445. This issue is just calling that we can start considering materializing the abstraction onto code level, but does not imply that which specific version of abstraction should we use. That's a separate discussion in #445, and should be determined before we take any action on this issue. :)
Based on PR #445 :
Now since we already have a clearly articulated input / output behavior, and one version of workflows of ASAPPlanner, can we materialize this logical picture to concrete lib functions visible to lib / cli users?
This means, we only expose to users what we conceptually described in the input / output and workload document, and all other internal steps are kept invisible to outside.
This will help future development by making iterating certain logical component much easier, since we only need replacing instead of appending.
Notice:
There's still some pending discussion on the specific content of input-output and workflow in #445. This issue is just calling that we can start considering materializing the abstraction onto code level, but does not imply that which specific version of abstraction should we use. That's a separate discussion in #445, and should be determined before we take any action on this issue. :)