The hardware and bandwidth for this mirror is donated by METANET, the Webhosting and Full Service-Cloud Provider.
If you wish to report a bug, or if you are interested in having us mirror your free-software or open-source project, please feel free to contact us at mirror[@]metanet.ch.
Transparency is one of the underpinning principles of ethical modelling practice. One way to improve the transparency of computational health economic models is to ensure that the programs implementing model analyses can be meaningfully inspected by readers with different levels of technical expertise. Even non-technical readers should be able to follow the high-level logic implemented by model algorithms. If multiple analysis programs are written using a common simplified syntax then reviewers of those programs need to contend with relatively fewer new concepts.
ready4
provides a simple syntax that can be consistently
applied to attach algorithms (methods) to model
modules. It does so by taking advantage of the abstraction
and polymorphism features of Object Oriented Programming and R’s use
of generic functions. Generic functions don’t implement algorithms
themselves - their most salient features are a name and a high level
description of the type of task that any method associated with that
generic should perform. Whenever a developer creates a method for
classes that use R’s S4 and S3 systems (the
types used for model modules and sub-modules), they can associate
that method with a generic that has a description that is a good match
for the algorithm being implemented.
ready4
includes a number of core generic functions which
describe the main types of method to be implemented by model modules.
These generics correspond exactly to the “core”, “slot” and “extended”
commands described in another
article.
Notably, the ready4
package does not associate any core
or extended methods with the Ready4Module
template
module. Instead, model developers need to decide which core and
extended generics they associate with the modules they derive from the
Ready4Module
template. This decision is typically made when
authoring the methods associated with model modules.
Currently, the only methods defined for Ready4Module
are
slot-methods.
By default, these slot methods are inherited by all modules derived from
the Ready4Module
template. These methods can be itemised
using the get_methods
function.
## [1] "authorSlot" "characterizeSlot" "depictSlot"
## [4] "enhanceSlot" "exhibitSlot" "ingestSlot"
## [7] "investigateSlot" "manufactureSlot" "metamorphoseSlot"
## [10] "procureSlot" "prognosticateSlot" "ratifySlot"
## [13] "reckonSlot" "renewSlot" "shareSlot"
These binaries (installable software) and packages are in development.
They may not be fully stable and should be used with caution. We make no claims about them.