[Bioc-devel] R6 and Bioconductor

Garth Ilsley garth.ilsley at oist.jp
Sat May 13 11:15:47 CEST 2017


A really helpful answer, thank you.

I dont speak for the project, but i would suggest that reference classes are really best/(almost) only useful for encoding state in complex/unusual-for-r package code. Having user-facing objects with these mechanics violates a pretty central idiom of R (copy on write) and thus is imo substantially more damaging than it is worth in general.

One of the things that makes r simpler for beginners than other languages is that when they pass an object to a function that function "can't" change the version they have in their workspace.


As you suggest, specifics matter, but thanks for explaining the context.

Refence classes absolutely can have active binding fields. It is pretty standard practice I think.

Thanks, I hadn’t realised that.

As for private fields, no they don't have that, but I've never really been convinced you need them in the vast vast majority of cases. R is designed such that the user owns their data (ie the contents of their objects). I've never really heard a good augment why that shouldn't be the case.

What I like is that they reduce clutter in the class interface, and more importantly, allow you to make it clear what part of the interface the user can expect to remain stable in future versions. They are the implementation details that might change.

That said the typical idiom in all of my code is to have paired fields, an active binding which is a function. That does some checking/processing and a classed field with the same name prepended with a . That it corresponds to.

Thanks for the pointer. Does the initial . suggest that the user shouldn’t make use of these fields directly i.e. does this fulfil the role of private field?

Also R6 aren't really compatible with reference class/S4 mechanics because the fields are not classed. This may sound like a small thing but imo it's actually quite important.


A good point.


	[[alternative HTML version deleted]]



More information about the Bioc-devel mailing list