Any reason why tracelib does not use R6 class?

[msevestre]

@ju-rgen I thought we had agreed to use R6 class for our projects. I see that tracelib uses the older setRefClass.

[ju-rgen]

See our decision documentation from that time below.

Should we migrate our implementation to R6 to use the same Class approach?

R6 a validated package (by Mango).

R6

• Unified class approach in PMx makes later maintenance of R code easier.
• Hadley Wickham prefers R6 over RC (see https://adv-r.hadley.nz/r6.html)
  • nicer style
  • private and public fields and methods
  • simpler cross package subclassing
  • R6 is faster than RC
  • R6 is more independent of R

RC

• no extra work to change the code
• typed fields, which make code more reliable and safe
• reflection (see e.g. getRefClass() / missing in R6, see Get class definition of R6 instance? r-lib/R6#144)
• included in standard R, no additional package validation necessary
  • TraceLib seems not to have any performance issues
  • cross package subclassing seems not necessary for TraceLib

Because we have nearly finished the main implementation of TraceLib and test development, documentation, etc. seems to be not affected by a switch from RC to R6 it seems to be the same effort to change now or later from RC to R6.
The working time of Jeevan is restricted, and the switch would take some days or work.

Therefore we do not switch now - perhaps later, when assessment of advantages and disadvantages is more stable.
Writing the tests before switching could even make switching easier later

[msevestre]

documentation, etc. seems to be not affected by a switch from RC to R6

This is not true. Documentation with rdoc is now supported for R6 class and you need to document at the method level and not globally like for RC class.

[msevestre]

I should correct: This is not true ANYMORE

It was at the time of decision however