On Tue, Jun 10, 2008 at 8:07 AM, John Chambers <[EMAIL PROTECTED]> wrote:
> 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? > I've thought about something along those lines. Something like a widget() generic. See Antony Unwin's article in the DSC 2001 proceedings entitled: "R objects, two interfaces! (R objects to interfaces?)" Michael > > 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 <[EMAIL PROTECTED]>: >>> >>> >>> On Tue, 10 Jun 2008, Laurent Gautier wrote: >>> >>> >>> >>> 2008/6/10 Prof Brian Ripley <[EMAIL PROTECTED]>: >>> >>> >>> 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@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/<http://www.stats.ox.ac.uk/%7Eripley/> >>> 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, [EMAIL PROTECTED] >>> Professor of Applied Statistics, >>> http://www.stats.ox.ac.uk/~ripley/<http://www.stats.ox.ac.uk/%7Eripley/> >>> 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 >>> >>> >>> >>> >>> >>> >> > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
