Thank you, John. Understood. The "is a" construct makes more sense for my purposes as the class users will "expect" matrix behavior.
Initially (no pun intended) it was counter-intuitive to me that initialize checked validity, but now it seems like a reasonable compromise. In the long term I will probably take advantage of the Matrix package. Thanks, all. No-longer-dead-in-the-water, Dan On Thu, May 6, 2010 at 9:34 AM, John Chambers <j...@r-project.org> wrote: > Re: the validity bug. It's just as your example suggests: the inherited > initialize() method for "matrix" fails to call validObject(). Should be > easy to fix. (Although it points out that the code should perhaps be > reorganized so the initialize() method is not responsible for checking > validity.) > > > Re: your other question: > > > On 5/6/10 4:09 AM, Martin Maechler wrote: > >> Daniel Murphy<chiefmur...@gmail.com> >>>>>>> on Wed, 5 May 2010 22:08:06 -0700 writes: >>>>>>> >>>>>> <snip> > > > Should I >> > 1) always put "matrix" into the setClass representation argument >> instead of >> > the contains argument, or >> > 2) use contains="numeric", put the matrix's dims and dimnames >> attributes >> > into slots, and rely on a constructor to populate the instance? >> >> > Either is possible, but if you really want your new objects to inherit the > properties of a matrix, your initial idea of contains="matrix" is the > natural choice for 2) (once the bug is fixed, but even before for most > purposes). The choice is to inherit from matrix or have matrix as a slot > (what Smalltalk called "is a" versus "has a"). > > The choice is as always whether you want to inherit all the methods and > then override the ones that DON'T make sense, or put the matrix in a slot > and write all the methods that DO make sense. > > Neither choice fits all examples but "matrix" is special, because R treats > them in a special (perhaps "weird" would apply) way: they are not a class > (not even an S3 class) but much code recognizes them internally, meaning you > inherit a great deal of stuff. > > If your new class of objects are supposed to act like matrices most of the > time, the contains= version may require a lot less programming. On the other > hand, if you planned to store the data in a non-standard way (as the Matrix > package does) then you really don't want to inherit the standard methods > because any you failed to override could be disastrous. > > > > Well, one can go the very long and "stable" way as we did in the >> Matrix package... >> >> I'm not sure I would recommend that for you in your situation. >> ... >> not the least because you *could* use the Matrix package if you >> want to use such formal matrices with its thousands of methods. >> >> Martin Maechler, >> ETH Zurich >> >> > Option 2 seems most "stable". >> >> > Thanks, >> > Dan Murphy >> >> > Windows Vista, R version 2.11.0 (2010-04-22) >> >> > [[alternative HTML version deleted]] >> >> > ______________________________________________ >> > R-devel@r-project.org mailing list >> > https://stat.ethz.ch/mailman/listinfo/r-devel >> >> ______________________________________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
