[Rd] S4 'object is not subsettable' in prototype

[Prof Brian Ripley]

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 
source.

> 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[1] 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:

> is.pairlist(NULL)
[1] TRUE
> identical(pairlist(), NULL)
[1] TRUE

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
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 

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