[Rd] another S4 question ...

[Martin Morgan]

Ben --

My vote would be against overriding the generic for show. If for some
reason your version proves inadequate, you force the user to
(conditional on loading your package) disambiguate 'show' to get the
methods package behavior.

?show says in part

     Formal methods for 'show' will usually be invoked for automatic
     printing (see the details).

and it's difficult to provide ... with automatic printing. On the
other hand, the naive user is probably expecting to be able to print()
your object (much as they are expecting to use 'as' rather than
'coerce'). ?show goes on to say

     The 'methods' package overrides the base definition of
     'print.default' to arrange for automatic printing to honor methods
     for the function 'show'.  This does not quite manage to override
     old-style printing methods, since the automatic printing in the
     evaluator will look first for the old-style method.

and the following might be a different solution

> setClass("A", representation=representation(x="numeric"))
[1] "A"
> print.A <- function(x, ...) cat("an A\n")
> print(new("A"))
an A

Another solution might be

> rm(print.A)
> setMethod("print", "A", function(x, ...) cat("another A\n"))
Creating a new generic function for "print" in ".GlobalEnv"
[1] "print"
> print(new("A"))
another A

This creates a 'print' generic with an identical signature to 'print',
which might be marginally better than creating another generic (for
'show') with a different signature. I think I'd still go with the
S3-style print, even though it mixes object systems, because it seems
to have the least potential to interfere with other packages.

Martin


Ben Bolker <bolker at zoo.ufl.edu> writes:

>   The default generic method for "show" has arguments
> show(object) -- (no "...")   -- which precludes any kind
> of arguments like "digits", etc.
>
>   Is it impossible, or a horrible idea, to override the
> generic definition?  (The "arm" package has defined a
> new generic, "display", which does a similar thing but
> has an intermediate level of detail (between "print/show"
> and "summary")
>
>   Ben Bolker
>
>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Martin Morgan
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M2 B169
Phone: (206) 667-2793