search

ivapylibs / puzzle_solver

1 stars 2 forks source link

Code: puzzle.solver.base #20

Closed pv33 closed 2 years ago

pv33 commented 3 years ago

There is now a puzzle.solver.base class. It pretty much does nothing, but exists to define a base class with overloadable member functions. The puzzle.solver.simple class should be modified to be a sub-class of it.

pv33 commented 3 years ago

@Uio96 If using a manager for the association, should the manager also be a member variable of all puzzle solvers? If all solvers need an association mechanism, then maybe it should be a necessary element for all solvers.

Uio96 commented 3 years ago

@Uio96 If using a manager for the association, should the manager also be a member variable of all puzzle solvers? If all solvers need an association mechanism, then maybe it should be a necessary element for all solvers.

Yep. I agree with this idea.

pv33 commented 3 years ago

@Uio96 OK, except that means a manager should probably have its own class hierarchy since there are many manager instance types. Mostly for testing purposes. Eventually, the full system will have one version as the go to one.

Own class hierarchy naturally means to have a namespace and be incorporated as a puzzle.manager package. You'll have to create an issue in this milestone to address that and then define a baseline class.

Will it be its own class with a member variable that does all the work so that it can be adjusted in sub-classes? Or will it be derived from a perceiver instance with all the flexibility of a perceiver plus extra functionality that gets encoded within the derived class?

Think it through and create a new issue with your justification.

Uio96 commented 3 years ago

@Uio96 OK, except that means a manager should probably have its own class hierarchy since there are many manager instance types. Mostly for testing purposes. Eventually, the full system will have one version as the go to one.

Own class hierarchy naturally means to have a namespace and be incorporated as a puzzle.manager package. You'll have to create an issue in this milestone to address that and then define a baseline class.

Will it be its own class with a member variable that does all the work so that it can be adjusted in sub-classes? Or will it be derived from a perceiver instance with all the flexibility of a perceiver plus extra functionality that gets encoded within the derived class?

Think it through and create a new issue with your justification.

See https://github.com/ivapylibs/puzzle_solver/issues/29#issue-972256116