---
title: "Provide End Users With A Simple And Consistent Syntax"
output: rmarkdown::html_vignette
vignette: >
  %\VignetteIndexEntry{Provide End Users With A Simple And Consistent Syntax}
  %\VignetteEngine{knitr::rmarkdown}
  %\VignetteEncoding{UTF-8}
---

```{r setup, include=FALSE}
knitr::opts_chunk$set(echo = TRUE, warning = FALSE)
```
```{r results='hide', message=FALSE, warning=F}
library(ready4) 
```

## Motivation
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. 

## Implementation
`ready4` provides a simple syntax that can be consistently applied to attach algorithms (methods) to [model modules](https://www.ready4-dev.com/docs/tutorials/develop-models/modularity/). It does so by taking advantage of the [abstraction and polymorphism features of Object Oriented Programming](https://www.ready4-dev.com/docs/framework/implementation/paradigm/object-oriented/#transparent-computational-models) 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)](https://www.ready4-dev.com/docs/tutorials/develop-models/modularity/#implementation), they can associate that method with a generic that has a description that is a good match for the algorithm being implemented.

## Use
`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](https://www.ready4-dev.com/docs/tutorials/use-models/authoring-analyses/commands/).

Notably, the `ready4` package does not associate any core or extended methods with the `Ready4Module` [template module](https://www.ready4-dev.com/docs/tutorials/develop-models/modularity/). 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](https://www.ready4-dev.com/docs/tutorials/use-models/authoring-analyses/commands/). 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. 

```{r}
get_methods()
```