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