Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

merge Result and Evaluation #254

Open
dave-doty opened this issue Mar 26, 2024 · 0 comments
Open

merge Result and Evaluation #254

dave-doty opened this issue Mar 26, 2024 · 0 comments
Assignees

Comments

@dave-doty
Copy link
Member

dave-doty commented Mar 26, 2024

Currently, there is a class Result that is returned by the evaluate function of a Constraint, and there is a related class Evaluation that contains (I think) all the information in a Result, plus additional information.

This seems redundant. We should just have evaluate return an Evaluation, with most of the fields not yet specified, and the search algorithm can later populate those fields rather than making a whole new object.

I think the reason they are separate is that I used to make an Evaluation only for constraint violations, whereas a Result was created for every evaluation of a constraint. However, that's no longer the case. We keep a list of all Evaluation's. But there still might be a good reason to keep these as separate classes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants