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 <jmc@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<chiefmurphy@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]]

