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

Proposal: Move __call__ in Zgr and make compute_z3 an abstract method #45

Open
malmans2 opened this issue Jun 25, 2021 · 0 comments
Open
Labels
design Design discussion

Comments

@malmans2
Copy link
Member

I'm having second thoughts about how we are using __init__ and __call__ in the zgr child classes.

The parent Zgr knows about jpk, but it doesn't do any computationally expensive stuff when it is initialized.
I.e., I don't think there's any advantage in initializing the class only once. I also think it is easier to do:

ds.domcfg.sco(jpk=31, **kwargs)

rather than

ds.domcfg.jpk = 31
ds.domcfg.sco(**kwargs)

I suggest we move __call__ in Zgr, where call does not have any argument and returns the final object with all z3 and e3.
The parent __init__ can stay as it is: __init__(obj, jpk).
Childs' __init__ would just add arguments to the parent __init__.

Finally, compute_z3 should be an abstract method in the parent class (Zgr), and that abstract method should be used by the parent class to generate z3 needed to compute e3.

Recap:

  1. Child classes should look like this: Zco(obj, jpk, ...). Child classes initialize additional arguments and their __init__ end with super().__init__(obj, jpk)
  2. The only constraint for child classes is that they have a method that computes and return z3. How they do it, it's not Zgr business.
  3. Direct call of classes looks like this ds_out = Zco(ds_in, jpk, **kwargs)()
  4. The public API looks like this: ds_out = ds_in.domcfg.zco(jpk, **kwargs)
@malmans2 malmans2 added the design Design discussion label Jun 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design Design discussion
Projects
None yet
Development

No branches or pull requests

1 participant