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 <[EMAIL PROTECTED]> 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@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, [EMAIL PROTECTED] 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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
