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

Interaction/cooperation between sketch modules #41

Open
3 of 14 tasks
ondrej33 opened this issue May 29, 2024 · 0 comments
Open
3 of 14 tasks

Interaction/cooperation between sketch modules #41

ondrej33 opened this issue May 29, 2024 · 0 comments

Comments

@ondrej33
Copy link
Member

ondrej33 commented May 29, 2024

So far, we have three individual sketch modules - model, properties, and observations. These are now mostly independent (except for the relationship between automatically generated static properties for the model's regulations). We will need the modules to interact more. For example, changing IDs of datasets needs to be propagated to dynamic properties that reference these datasets. We should try to think of ways how to do that, and we should start implementing these interactions.

General design of the communication

The modules will probably interact more and more in the future (several sketch components might need to cooperate in the analysis phase). Currently, that could be done via

  • Events broadcasting - if an event should affect more than one component, the sketch object can broadcast it to all affected modules. This will probably be useful for one-way independent events that just need to update more things at once.

need to update the regulation sign (in both model and properties) - the change_sign is distributed to both the model and properties and updated independently (nothing to fail)

  • Main event that handles the rest - there will be just one component handling the main event. It does the bulk of the preprocessing work and then (depending on previous steps) generates several other events.

need to add regulation (in both model and properties) - the original add_regulation event is handled by the model (all of the consistency checks) and then broken down and "restarted" (into add_regulation_raw, add_property, and so on)

Implementing the existing interactions

There are already several events that affect more than one component.

We should propagate the following data changes to dynamic properties:

  • dataset removed
  • dataset's whole content changed
  • dataset's ID changed
  • observation removed (popped)
  • observation's ID changed

The following model changes should be propagated to static properties (if needed):

  • variable removed
  • variable's ID changed
  • function removed
  • function's ID changed
  • function's arity changed (decremented)
  • fn argument's monotonicity/essentiality changed
  • regulations monotonicity/essentiality changed
  • regulation created
  • regulation removed

Of course, all of this will need some more complex integration testing. We should update the event testing workflow to reflect that.

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

1 participant