Reverse effects class definition
Closed this issue · 2 comments
Current state
Current effects specification follow init/update_model_submodel.effect naming convention.
It creates a code/documentation mismatch: Functions or methods with usage in documentation object 'goldfishEffects' but not in code; and Objects in \usage without \alias in documentation object 'goldfishEffects'.
Describe propose solution
The alternative is to define classes for the effects with the following structure effect.model.submodel.type.init/update with the "type" being directed/undirected classification.
A distinction between the rate and the choice sub-models helps provide the correct model effect to the users. Still, the direct undirect network type might introduce additional issues.
Example: choice-coordination submodel should allow direct effects when the covariate network is directed (in-degree).
In another case, it should forbid(create a warning?) the effect use (for directed networks trans, cycle give the same result).
What about effect.model-submodel.type.init? That is, model and submodel get paired (currently there is no rate-coordination model anyway).