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

Default ROMSComponent instance / lack of substitutability #116

Open
dafyddstephenson opened this issue Sep 30, 2024 · 0 comments
Open

Default ROMSComponent instance / lack of substitutability #116

dafyddstephenson opened this issue Sep 30, 2024 · 0 comments
Labels
design top-level design question

Comments

@dafyddstephenson
Copy link
Contributor

As mentioned in #115 , the design of Component reflects the needs of many earth subsystem models:

  • A base model
  • Model discretization information
  • Input datasets
  • Namelist files (runtime code)
  • Additional source code files (compile-time code)

In the Component base class, with the exception of the base model, those from this list (that are defined, see #115) are listed as Optional. We can easily imagine a Component not needing one or many of these things.

For instance, we would anticipate only rarely needing additional source code files. This was in fact only added to alpha because of ROMS' need for it. This presents an issue: for ROMS, Additional source code files are required for any reasonable level of control over the model, including switching entire model subsystems on or off. Thus, for the ROMSComponent subclass, these are NOT optional.

This violates the Liskov substitution principle, as we have an optional attribute on the base class that is required in a subclass.

I believe the best remedy here would be to also make these optional in the subclass, set a default value, and raise a warning that the default value has been invoked.

This means we should have a "default" ROMS component that is initialised if you just call ROMSComponent(base_model = some_version_of_roms) with no other arguments.

@dafyddstephenson dafyddstephenson added the design top-level design question label Sep 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design top-level design question
Projects
None yet
Development

No branches or pull requests

1 participant