Supersede shlab.imgct in favor of class-prefixed itrackvalr
Problem
We are developing multiple packages when we should instead consolidate into one package. At this point, this means superseding shlab.imgct into itrackvalr. How can we do this, and follow best practices for R packages and target audience usability?
Solution
I’m thinking the right strategy is to build shlab.imgct into itrackvalr as a self-contained internal toolkit. Then we work within a single package that is namespaced as in itrackvalr::func() for an exported function func().
As an additional step with big dividends, we implement prefixed function class, sort of like a collection of related methods (relation typically dependent on data types, so description fits well here). This might make it itrackvalr::ic_func(), where ic is our class for image categorization. Similarly, we could include iv as our class for image valuation, where this is for methods related to the emotion rating data. Both in case of a future iteration of the task that uses different images, which seems very possible. That then leaves et for eye tracking, br for behavioral responses, and qs for questionnaires/self-report.
Additional Notes
For the most part, I consider the above classes to be most useful as a strategy to modularize and make simpler the pre-processing stage, where much of the work is related to the class-specific data sets. We might find that we want other class prefixes as we move toward analysis, visualization, etc. A good rule of thumb is that if we have more than three functions related to the same unique concept, we might want to consider adding a class.
Supersede
shlab.imgct
in favor of class-prefixeditrackvalr
Problem
We are developing multiple packages when we should instead consolidate into one package. At this point, this means superseding
shlab.imgct
intoitrackvalr
. How can we do this, and follow best practices for R packages and target audience usability?Solution
I’m thinking the right strategy is to build
shlab.imgct
intoitrackvalr
as a self-contained internal toolkit. Then we work within a single package that is namespaced as initrackvalr::func()
for an exported functionfunc()
.As an additional step with big dividends, we implement prefixed function class, sort of like a collection of related methods (relation typically dependent on data types, so description fits well here). This might make it
itrackvalr::ic_func()
, whereic
is our class for image categorization. Similarly, we could includeiv
as our class for image valuation, where this is for methods related to the emotion rating data. Both in case of a future iteration of the task that uses different images, which seems very possible. That then leaveset
for eye tracking,br
for behavioral responses, andqs
for questionnaires/self-report.Additional Notes
For the most part, I consider the above classes to be most useful as a strategy to modularize and make simpler the pre-processing stage, where much of the work is related to the class-specific data sets. We might find that we want other class prefixes as we move toward analysis, visualization, etc. A good rule of thumb is that if we have more than three functions related to the same unique concept, we might want to consider adding a class.
Advanced option
See R6 classes: https://adv-r.hadley.nz/r6.html