str and s3 classes
> These are obvious toy examples, but it is a real problem
> if you want to create a class that defines names or length
> in a meaningful way, that is incompatible with the
> underlying data structure.
Yes indeed, (and "well know"). I'm arguing that in such a situation, i.e., where you explicitly let length() --- or `[` --- behave incompatibly with respect to the underlying data structure, you have to define your own str() S3 method. I/we have done so ourselves in quite a few cases; typically this is a 1- or 2-liner, possibly calling utils:::str.default(). I do actually think we should *un*hide str.default() for such situations.
That would be useful!
In such a case (and not only here), using an S4 class instead of an S3 is much more natural IMO.
Be that as it may, it would still be nice for str to work with S3 objects with potentially incorrect length and names methods - str is particularly useful when debugging. Part of the problem is I don't how to force internally dispatched generics to use the default case - if the generic uses regular dispatch you can always use generic.default() (or similar), but I don't think it's possible to do the same for an internal generic (without copying the object, which is obviously undesirable)? Hadley -- Chief Scientist, RStudio http://had.co.nz/