[Rd] show vs print (Re: Error in "getClass" when calling the function "show")
John Chambers
jmc at r-project.org
Tue Jun 10 17:07:29 CEST 2008
It's now perhaps only a historical point, but one motivation for
introducing show() in S4 was the thought that something other than
"printing" might evolve to be better for "showing" an object (e.g., a
method that displayed the object graphically). The name was chosen to
be neutral about how the object was shown.
Perhaps, though, this is an idea that might be due for revival. There
have been some striking uses of interactive tables/graphs in the
non-scientific literature recently to display rich data "objects".
Maybe we should be looking more closely at these for ideas. For
example, several people have pointed out a New York Times graphic
http://graphics8.nytimes.com/packages/flash/politics/20080603_MARGINS_GRAPHIC/margins.swf
(Jan de Leeuw, and others) for displaying tables of results of the
recent US presidential primaries. Might we design interactive "show"
methods for complex objects?
Prof Brian Ripley wrote:
> On Tue, 10 Jun 2008, John Chambers wrote:
>
>> The function show() is intended as a mechanism for automatic display of
>> objects, a vehicle for writing methods that control the automatic
>> display
>> of new classes of objects (as noted in its documentation and in
>> "Programming with Data").
>>
>> That's why, unlike print() or plot(), it has no optional arguments to
>> control its behavior.
>>
>> That said, it was always intended to call print() for S3 objects, as
>> would be obvious from reading the code for showDefault(). It's just a
>> glitch that it doesn't, as Brian inferred. We'll fix it, and your usage
>> should then be perfectly OK. (The relevance of efficiency when one is
>> printing objects for humans to look at is not compelling.)
>
> Not compelling, but there are more hoops to jump through, and hence
> more to fail (as here). One point that is a little more serious is
> that show() is in methods, and with S3 objects it might be the case
> that the methods package is not loaded and hence show() is not visible.
>
> For completeness, I should point out that you can define S4 methods
> for print() and S4 methods for show() for S3 classes. If you do that,
> things may not work consistently (not least because you will have an
> S4 generic 'print' that may not be found in preference to
> base::print), but we do discourage it.
>
> I find it is rarely needed to call print() or show() explicitly, and
> when I do I follow the same rule as auto-printing - use show() when I
> know I have an S4 object and print() otherwise.
>
>>
>> John
>>
>> Laurent Gautier wrote:
>>
>> 2008/6/10 Prof Brian Ripley <ripley at stats.ox.ac.uk>:
>>
>>
>> On Tue, 10 Jun 2008, Laurent Gautier wrote:
>>
>>
>>
>> 2008/6/10 Prof Brian Ripley <ripley at stats.ox.ac.uk>:
>>
>>
>> showDefault has
>>
>> clDef <- getClass(class(object))
>>
>> Looks like the showDefault code intended
>>
>> clDef <- getClass(class(object), .force=TRUE)
>>
>> However, why are you calling show() on a non-S4 object? I cannot see
>> any
>> advtanges in doing so.
>>
>>
>> I'd like *one* printing method for all objects, and the generic "show"
>> is registered as working for ANYthing (see below) ?
>>
>>
>> print() calls show() for S4 objects (with no additional arguments).
>>
>> I agree show() ought to do what it is documented to, but calling it on
>> non-S4 objects is inefficient.
>>
>>
>> Fair enough.
>> May be that word of caution could appear in the documentation for
>> "show" then ?
>>
>> A good place could be where the documentation says:
>> The 'methods' package overrides the base definition of
>> 'print.default' to arrange for automatic printing to honor methods
>> for the function 'show'.
>>
>> which led me to think that "show" is covering more cases than "print"
>> does
>> (while apparently the opposite is happening with "print" delegating
>> to "show").
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Laurent
>>
>>
>>
>>
>>
>>
>> Or is defining one's own function currently recommended ?
>>
>> myPrint <- function(x, ...)
>> {
>> if (isS4(x)) {
>> show(x, ...)
>> } else {
>> print(x, ...)
>> }
>> }
>>
>>
>>
>> showMethods("show")
>>
>>
>> Function: show (package methods)
>> object="ANY"
>> object="classRepresentation"
>> object="derivedDefaultMethod"
>> (inherited from: object="MethodDefinition")
>> object="function"
>> (inherited from: object="ANY")
>> object="genericFunction"
>> object="MethodDefinition"
>> object="MethodsList"
>> (inherited from: object="ANY")
>> object="MethodWithNext"
>> object="ObjectsWithPackage"
>> object="signature"
>> object="traceable"
>>
>>
>>
>> showMethods("print")
>>
>>
>> Function "print":
>> <not a generic function>
>>
>>
>> getMethod("show", "ANY")
>>
>>
>> Method Definition (Class "derivedDefaultMethod"):
>>
>> function (object)
>> showDefault(object, FALSE)
>> <environment: namespace:methods>
>>
>> Signatures:
>> object
>> target "ANY"
>> defined "ANY"
>>
>>
>>
>>
>> On Tue, 10 Jun 2008, Laurent Gautier wrote:
>>
>>
>>
>> Dear List,
>>
>> Calling "show" on an object of class "summary.lm" gives:
>> Error in getClass(class(object)) : "summary.lm" is not a defined class
>>
>> Is this a miss on my end ?
>>
>>
>>
>>
>> x <- seq(1, 10)
>> show(x)
>>
>>
>> [1] 1 2 3 4 5 6 7 8 9 10
>>
>>
>> y <- runif(10)
>> fit <- lm(y ~ x)
>> show(fit)
>>
>>
>> Call:
>> lm(formula = y ~ x)
>>
>> Coefficients:
>> (Intercept) x
>> 1.04938 -0.08869
>>
>>
>>
>> show(summary(fit))
>>
>>
>> Error in getClass(class(object)) : "summary.lm" is not a defined class
>>
>>
>> class(summary(fit))
>>
>>
>> [1] "summary.lm"
>>
>>
>> class((fit))
>>
>>
>> [1] "lm"
>>
>>
>> getClass("lm")
>>
>>
>> Virtual Class
>>
>> No Slots, prototype of class "S4"
>>
>> Extends: "oldClass"
>>
>> Known Subclasses:
>> Class "mlm", directly
>> Class "aov", directly
>> Class "glm", directly
>> Class "maov", by class "mlm", distance 2
>> Class "glm.null", by class "glm", distance 2
>>
>>
>> getClass("summary.lm")
>>
>>
>> Error in getClass("summary.lm") : "summary.lm" is not a defined class
>>
>>
>> sessionInfo()
>>
>>
>> R version 2.7.0 Patched (2008-06-07 r45877)
>> i686-pc-linux-gnu
>>
>> locale:
>>
>>
>> LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
>>
>>
>> attached base packages:
>> [1] stats graphics grDevices utils datasets methods base
>>
>>
>> Laurent
>>
>> ______________________________________________
>> 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
>>
>>
>>
>> --
>> 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
>>
>>
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>>
>>
>>
>
More information about the R-devel
mailing list