Open smishr opened 1 year ago
We need to update all the functions and think carefully. How about:
abstract type ReplicateDesign end
struct BootstrapDesign <: ReplicateDesign
end
struct JackknifeDesign <: ReplicateDesign
end
?
Then we can do multiple dispatch instead of if else ladders.
I wish there was inheritance. We could have done BoostrapDesign <: ReplicateDesign <: SurveyDesign
We need to update all the functions and think carefully. How about:
abstract type ReplicateDesign end struct BootstrapDesign <: ReplicateDesign end struct JackknifeDesign <: ReplicateDesign end
?
Then we can do multiple dispatch instead of if else ladders.
I wish there was inheritance. We could have done BoostrapDesign <: ReplicateDesign <: SurveyDesign
Yes something like this should improve the modularity of the code.
But we need to throughly think this through. All other parts of the package should be made modular as well at the same time
How do other packages solve the inheritance issues?
I haven't looked through the code too much, but a partial solution presents itself:
abstract type AbstractSurveyDesign end
struct SurveyDesign <: AbstractSurveyDesign
...
end
abstract type AbstractReplicateDesign <: AbstractSurveyDesign end
struct BootstrapDesign <: AbstractReplicateDesign
end
struct JackknifeDesign <: AbstractReplicateDesign
end
so you basically introduce a top-level abstract type, which SurveyDesign and AbstractReplicateDesign both subtype. Then, generic methods can be dispatched on AbstractSurveyDesign. I've used this pattern, and seen it used, in a number of places (most notably as Number -> (Real -> ..., Complex)
).
I haven't looked through the code too much, but a partial solution presents itself:
abstract type AbstractSurveyDesign end struct SurveyDesign <: AbstractSurveyDesign ... end abstract type AbstractReplicateDesign <: AbstractSurveyDesign end struct BootstrapDesign <: AbstractReplicateDesign end struct JackknifeDesign <: AbstractReplicateDesign end
so you basically introduce a top-level abstract type, which SurveyDesign and AbstractReplicateDesign both subtype. Then, generic methods can be dispatched on AbstractSurveyDesign. I've used this pattern, and seen it used, in a number of places (most notably as
Number -> (Real -> ..., Complex)
).
@ayushpatnaikgit @codetalker7 what do you guys think here?
Ah, I just realized I suggested two different approaches :D - let's discuss on the call if any of those make sense.
See line 22-27 in by.jl
This is hardcoding the variance for "bootstrap" type
ReplicateDesign
. For future additions, likeJKn
, the variance is calculated differently.TODO: Update bydomain function with modularity for current and future methods of variance estimation.