Re: [Rd] promptClass misses methods

From: Martin Maechler <>
Date: Sat 02 Dec 2006 - 16:11:22 GMT

>>>>> "RossB" == Ross Boylan <> >>>>> on Fri, 1 Dec 2006 11:33:21 -0800 writes:

    RossB> On Fri, Dec 01, 2006 at 11:37:46AM +0100, Martin
    RossB> Maechler wrote:

>> >>>>> "RossB" == Ross Boylan <>
>> >>>>> on Thu, 30 Nov 2006 22:29:06 -0800 writes:
    RossB> I've had repeated problems with promptClass missing
    RossB> methods, usually telling me a class has no methods
    RossB> when it does.

    RossB> In my current case, I've defined an S4 class
    RossB> "mspathCoefficients" with a print method
    RossB> setMethod("print", signature(x="mspathCoefficients"),
    RossB> function(x, ...)  { # etc

>> You should *not* define "print" methods for S4 classes;
>> rather you should define "show" methods.

    RossB> Is that because print is used by the S3 system?

no, not really.

    RossB> And is the general rule to avoid using S3 methods for S4     RossB> classes?

Well your wording is murky, but no, you *should* define (S4) methods for S3 generics very well. The S3 generics are automagically promoted to S4 generics as soon as you define an S4 method for it.

print() is just a big exception.

    RossB>   For example,, which is
    RossB> referenced in the package help for methods, discusses
    RossB> show, print and plot as 3 alternatives in S4 (p. 9,
    RossB> though a footnote says that at that time--2001--R
    RossB> didn't recognize formal methods for printing
    RossB> objects.)

2001 is way in the past concerning S4 implementation in R. Specifically, using S4 in R; we'd **very strongly** recommend R 2.4.0 (and ideally even R-patched) because of several recent good developments.

    RossB> I've been unable to locate much information about
    RossB> combining S3 and S4 methods, though I recall seeing a
    RossB> note saying this issue was still to be addressed in
    RossB> R.  Perhaps it has been now, with setOldClass?  At
    RossB> any rate, the help for that method addresses classes
    RossB> rather than methods, and I didn't see anything in
    RossB> ?Methods, ?setMethod, or ?setGeneric.

    RossB> show() raises two additional issues for me.  First,
    RossB> it takes a single argument, and I want to be able to     RossB> pass in additional arguments via ... .

That's not possible currently.

And I agree that in certain cases, I would want to have the flexibility of print(..) there;
One case is for printing/showing fitted LMER objects; the following code is used :

  ## This is modeled a bit after print.summary.lm :   printMer <- function(x, digits = max(3, getOption("digits") - 3),

		       correlation = TRUE, symbolic.cor = x$symbolic.cor,
		       signif.stars = getOption("show.signif.stars"), ...)


  setMethod("print", "mer", printMer)
  setMethod("show", "mer", function(object) printMer(object))

    RossB> Second, I read some advice somewhere, that I no
    RossB> longer can find, that show methods should return an
    RossB> object and that object in turn should be the thing
    RossB> that is printed.  I don't understand the motivation
    RossB> for that rule, at least in this case, because my
    RossB> object is already a results object.

I think you're confusing show() with summary(): The latter is should typically compute an object which then has a print/show method.

    RossB> The file promptClass creates has no methods in it.
>> >> showMethods(classes="mspathCoefficients")

    RossB> Function: initialize (package methods)
    RossB> .Object="mspathCoefficients" (inherited from:
    RossB> .Object="ANY")

>> so it's just inherited from "ANY"

    RossB> Function: print (package base) x="mspathCoefficients"
>> that's the one

    RossB> So why isn't promptClass picking it up?


    RossB> Function: show (package methods)
    RossB> object="mspathCoefficients" (inherited from:
    RossB> object="ANY")

>> so it's just inherited from "ANY"
>> Ross, it would really be more polite to your readers if
>> you followed the posting guide and posted complete
>> fully-reproducible code...

    RossB> I thought it might be overkill in this case.

It never is. We do want self-contained executable code.. In your case, I assumed it might have been things in a namespace in a package, ...

    RossB> At any rate, it sounds as if I may be trying to do the wrong
    RossB> thing, so I'd appreciate guidance on what the right
    RossB> thing to do is.

    RossB> Here's a toy example:

    RossB> setClass("A", representation(x="numeric"))
    RossB> setMethod("print", signature(x="A"), function(x, ...) print(x@x, ...) )
    RossB> promptClass("A")

    RossB> The generated file has no print method.  

Indeed, I can confirm that.

>> >> getGeneric("print")

    RossB> standardGeneric for "print" defined from package     RossB> "base"

    RossB> function (x, ...)  standardGeneric("print")
    RossB> <environment: 0x84f2d88> Methods may be defined for
    RossB> arguments: x


    RossB> I've looked through the code for promptClass, but     RossB> nothing popped out at me.
    RossB> It may be relevant that I'm running under ESS in
    RossB> emacs.  However, I get the same results running R
    RossB> from the command line.

    RossB> Can anyone tell me what's going on here?  This is
    RossB> with R 2.4, and I'm not currently using any namespace
    RossB> for my definitions.

>> [and not a package either?]
    RossB> The code is part of a package, but I'm developing code snippets in     RossB> ESS without loading the whole package.
>> I'm very willing to look at this, once
>> you've provided what the posting guide asks for, see above.

so now that I've promissed it; I'll have to look at it ;-) Probably too late to get a fix into R 2.4.1 though.


    RossB> Thank you. For completeness, here's some system info:

>> sessionInfo()

    RossB> R version 2.4.0 (2006-10-03)     RossB> i486-pc-linux-gnu

    RossB> locale:

    RossB> attached base packages:
    RossB> [1] "methods"   "stats"     "graphics"  "grDevices" "utils"     "datasets" 
    RossB> [7] "base"     

    RossB> The Debian package is r-base-core

    RossB> Ross mailing list Received on Sun Dec 03 07:09:14 2006

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.1.8, at Sat 02 Dec 2006 - 20:30:58 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.