From h.wickham at gmail.com  Fri Jun 21 15:30:14 2013
From: h.wickham at gmail.com (Hadley Wickham)
Date: Fri, 21 Jun 2013 08:30:14 -0500
Subject: [Rd] str and s3 classes
In-Reply-To: <20932.979.94491.579003@stat.math.ethz.ch>
References: <CABdHhvH08vczUYU=gkcg4-BHypugmtP7GvgfNgWt5YPmXK0quA@mail.gmail.com>
	<20932.979.94491.579003@stat.math.ethz.ch>
Message-ID: <CABdHhvHEGUO=K2aC-BzTZwzH1ro4_MKBj-=iZ+QqST36_f4ObA@mail.gmail.com>

>     > 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/



[Rd] str and s3 classes
Hadley Wickham