Migrate Reference Classes to R6 for Improved Performance, Flexibility, and Maintainability

[fpahlke]

Summary

The current implementation of randomforge uses R Reference Classes (setRefClass) for core objects such as RandomProject, RandomConfiguration, RandomSubject, RandomBlock, and others.
While Reference Classes were an important step in introducing OOP into R, they have several limitations in terms of performance, flexibility, and ecosystem support.

To ensure that randomforge can evolve into a modern, extensible, and high-performance framework, we propose a systematic migration of all Reference Classes to R6.

Motivation

There are several strong reasons for moving to R6:

1. Performance Improvements

R6 is significantly faster than Reference Classes, especially in:

• method dispatch
• field access
• object construction
• cloning and copying

For a randomization framework that may handle large numbers of subjects, blocks, strata, or simulations, these performance gains are extremely valuable.

2. Cleaner and More Modern OOP

R6 supports:

• public, private, and active bindings
• predictable inheritance
• method chaining
• explicit initializers
• lightweight object creation

This leads to cleaner APIs and more maintainable code.

Reference Classes are widely considered legacy, while R6 is the de facto standard in modern R OOP frameworks (tidyverse, Shiny, plumber, etc.).

3. Better Interoperability with Other Packages

Many contemporary R packages, especially those related to:

• Shiny
• plumber APIs
• simulation frameworks
• tidyverse-style data pipelines

use R6-style OOP.

Switching to R6 ensures that randomforge integrates naturally with these tools and avoids awkward bridges between R5-style and modern structures.

4. More Flexibility for Future Extensions

As randomforge grows into a broader ecosystem (e.g., adding new randomization engines, simulation modules, audit trails, Shiny UIs, API layers):

• R6’s encapsulation
• flexible class hierarchies
• clearer object semantics

make it easier to:

• plug in new randomization methods
• override behavior
• attach new modules
• maintain backward compatibility

5. Community Contributions Become Easier

R6 is familiar to most R developers in 2025.
Reference Classes are not.

Migrating to R6 lowers the barrier to entry for contributors and makes class implementations easier to understand and extend.

Proposed Plan

1. Introduce an internal R6 framework in parallel to the existing RC implementation.
2. Port individual Reference Classes step-by-step (starting with RandomProject and RandomConfiguration).
3. Provide compatibility wrappers if needed.
4. Update documentation and vignettes.
5. Deprecate the RC-based classes after migration is complete.

References

• R6 documentation: https://r6.r-lib.org/
• Hadley Wickham: Advanced R – OOP in R
• General R community discussions on RC → R6 transitions