Just to add to what Gabe already said, defer your performance concerns until you've actually got something that works and is well written. If you hit up against a performance barrier, come back and we can help.
On Fri, May 12, 2017 at 4:22 PM, Garth Ilsley <garth.ils...@oist.jp> wrote: > Thank you. > >> One place where one might think of using R6 is in the implementation of a >> mutable data model underlying a GUI like a Shiny app. > If mutable semantics >> are required, consider using S4 reference classes, as they offer more >> features than R6 and will integrate >> directly with Bioconductor S4 classes. > > If I understand correctly, you are saying that it is fine to use Reference > classes (mutable semantics) in Bioconductor. A GUI is one clear place for > this. However, what about a large dataset that is subject to progressive > analysis with various fields updated as the analysis proceeds? The typical > Bioconductor approach (as far as I have seen) is to call a method defined for > an S4 functional class that produces a new object of the same class, with the > result assigned to the same name as the original object. For a project > considered in isolation, it wouldn't be unreasonable to use a Reference class > for this instead, but that's not what I'm asking. My question is about the > standards and approach that Bioconductor has agreed on - to ensure > consistency. Is a Reference Class permissible in this situation? If not, case > closed. If they are permitted, I would suggest that R6 semantics are > consistent with Reference Class semantics, but with the added benefit of > private members and "active bin di > ngs" (they look like fields, but call a function). This is nice and simple > (for the creator and user of the class), but if not desired (for consistency > etc.), then I presume Reference Classes will do fine. > > > _______________________________________________ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel