On Tue, Jun 10, 2008 at 8:07 AM, John Chambers <jmc@r-project.org> 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 <ripley@stats.ox.ac.uk>:
>>>
>>>
>>>  On Tue, 10 Jun 2008, Laurent Gautier wrote:
>>>
>>>
>>>
>>>  2008/6/10 Prof Brian Ripley <ripley@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@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>>
>>>  --
>>> Brian D. Ripley,                  ripley@stats.ox.ac.uk
>>> 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,                  ripley@stats.ox.ac.uk
>>> 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]]

