As far as separating implementation from interface, a fairly simple separation is fields are implementation, methods are interface. While active bindings allow encapsulated fields (often called "properties" in other languages), it puts extra cognitive load on the user to remember which state components are fields and which are returned by methods. Some frameworks use properties to enable observation of mutable state (see the objectProperties package on CRAN for doing this with reference classes). But with reactivity in vogue, it's not clear whether the explicit observer pattern is still relevant.
Michael On Sat, May 13, 2017 at 2:15 AM, Garth Ilsley <garth.ils...@oist.jp> wrote: > 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]] > > _______________________________________________ > 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
