Ross Boylan <[EMAIL PROTECTED]> writes: > The code has a couple of decisions for which I could imagine > alternatives. First, even simple get/set operations on class elements > are wrapped in functions. I suppose I could just use [EMAIL PROTECTED] to > do some of these operations, though that is considered bad style in more > traditional OO contexts.
I like the get/set approach as opposed to using '@'. As long as users don't use '@' you have a fair amount of flexibility to redesign/refactor your code. > Second, even though the functions are tied to the class, I've defined > them as free functions rather than methods. I suppose I could create a > generic that would reject most arguments, and then make methods > appropriately. If anyone else is going to extend your classes, then you are doing them a disservice by not making these proper methods. It means that you can control what happens when they are called on a subclass. > For the documentation, I've created a single page that groups many of > the functions together. This is a bit awkward, since the return values > are necessarily the same. Things are worse for replacement functions; > as I understand it, they must use "value" for their final argument, but > the value has different meanings and types in different contexts. > > Any suggestions or comments? For accessors, I like to document them in the methods section of the class documentation. + seth -- Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center http://bioconductor.org ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
