[Rd] S4 'object is not subsettable' in prototype
Prof Brian Ripley
ripley at stats.ox.ac.uk
Mon Aug 21 21:30:04 CEST 2006
On Mon, 21 Aug 2006, John Chambers wrote:
> Aside from the statements in manuals & the blue book, there are many
> uses of length() in the code (R and C both) that don't seem to do any
> checking in advance for whether the operation makes sense.
I understood it was defined to always make sense (and to be one for
indivisible objects). As a historical note, I was surprised by the
statement in Bill Venables' 1990 notes that are the basis of `An
Introduction to R', and he rightly pointed me at the Blue Book for the
> We shouldn't take any of that as prohibiting a revision; as Robert says,
> the view of objects in the blue book is much less general than what we
> have now. On the other hand, I don't think it's the use of length()
> itself that was the chief bane of the list() version of S4 objects, but
> the more general fact that basic computations ended up treating the
> objects as vectors of type "list". Now that the S4 objects are not
> vectors when they shouldn't be, I would not expect length() to cause a
> huge confusion on its own. If it does, we can re-examine what to do.
> And, as footnote, the confusion isn't entirely due to S4 objects. You
> can create an object x for which is.vector(x) is FALSE but for which
> length(x), x, x and other computations go through with no
> complaints. And all without the benefit of any methods, S3 or S4. Just do
> x <- NULL
That I believe comes from the pairlist heritage:
> identical(pairlist(), NULL)
and length() and [ are defined for pairlists, hence for NULL.
I'd be quite happy for length(<S4SEXP>) to be one, which is the default
in the C-level function of that name. Just not an error.
> Seth Falcon wrote:
> > John Chambers <jmc at r-project.org> writes:
> >> When I was introducing the special type for S4 objects, my first
> >> inclination was to have length(x) for those objects be either NA or an
> >> error, along the lines that intuitively length(x) means "the number of
> >> elements in the vector-style object x". However, that change quickly
> >> was demonstrated to need MANY revisions to the current code.
> > Perhaps some details on the required changes will help me see the
> > light, but I would really like to see length(foo) be an error (no such
> > method) when foo is an arbitary S4 class.
> > I have encountered bugs due to accidental dispatch -- functions
> > returning something other than an error because of the zero-length
> > list implementation of S4. It would not be surprising if some of the
> > breakage caused by removing this "feature" identifies real bugs.
> > I was thinking that one of the main advatnages of the new S4 type was
> > to get away from this sort of accidental dispatch. Not trying to be
> > snide, but what is useful about getting a zero for length(foo)? The
> > main use I can think of is in trying to identify S4 instances, but
> > happily, that is no longer needed.
> > + seth
> [[alternative HTML version deleted]]
> R-devel at r-project.org mailing list
Brian D. Ripley, ripley at stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
More information about the R-devel