Re: [Rd] S4 generating function

From: John Chambers <jmc_at_r-project.org>
Date: Fri 05 Aug 2005 - 19:18:50 GMT

Re:
 > If I understand your description correctly, the problem is  > passing both named and unnamed arguments to callNextMethod().

No, as I said the distinction is a potential bug in callNextMethod _whenever_ it gets explicit arguments. (At the moment, it seems to be a bug in substitute() or else a different interpretation of that function from the one in the Blue Book. But I've only looked a little.)

So to work around it you have to be able to do callNextMethod() with no arguments.

Just at a guess, you may be able to do that if you avoid redefining the formal arguments for the initialize() method. Leave them as .Object, ... and extract the id= component.

   dotArgs <- list(...)
   id <- dotArgs$id

Or, wait for a fix. There should at least be one in r-devel sometime fairly soon.

Paul Roebuck wrote:

> On Fri, 5 Aug 2005, John Chambers wrote:
>
>

>>Paul Roebuck wrote:
>>
>>
>>>Can someone explain what the problem is when I use the
>>>generating function? And how to get debug() to stop in
>>>the Superclass initialize method?
>>>[SNIP code & output]
>>
>>Now, the specific example.  There are 3 special features used:
>>1. Nonstandard arguments for the initialize method (its official
>>arguments are (.Object, ...))
>>
>>2. callNextMethod
>>
>>3. within callNextMethod, providing explicit arguments.  The simple case
>>is callNextMethod(), which passes on the arguments to the current method.
>>
>>Turns out that it's the third step that finds a bug in the heuristics
>>used by callNextMethod to construct the actual call.
>>
>>In your example, you don't need the explicit arguments since they just
>>replicate the formal arguments to initialize().  If you omit them, the
>>computation is simpler & works.
>>
>>The bug can probably be fixed, but until 2.2 comes out at least, you
>>need to stick to the simpler callNextMethod().
>>[SNIP modified code]

>
>
> Thank you for your help. Unfortunately, this is a case where
> posting the simplest code necessary to display the bug works
> against the poster. Actual code uses external pointers but
> this revision shows more of the general concept.
>
> If I understand your description correctly, the problem is
> passing both named and unnamed arguments to callNextMethod().
> Can I [easily] do either of these things to avoid the bug?
>
> 1) somehow add an argument to 'dots' and invoke callNextMethod()
> without arguments?
> 2) parse 'dots' and invoke callNextMethod() with a completely
> named argument list?
>
>
> ------ revised source -------
> setClass("Superclass",
> representation(.values = "integer",
> id = "character"),
> contains = "VIRTUAL")
>
> setMethod("initialize",
> signature(.Object = "Superclass"),
> function(.Object, .values = NULL, id = "") {
> cat("initialize (Superclass)", "\n")
> if (!is.null(.values)) {
> cat("\t.values =", .values, "\n")
> .Object@.values <- .values
> }
> if (length(id) > 0) {
> cat("\tid =", id, "\n")
> .Object@id <- id
> }
> .Object
> })
>
> setClass("Subclass",
> contains = "Superclass")
>
> setMethod("initialize",
> signature(.Object = "Subclass"),
> function(.Object, count = 1, ...) {
> cat("initialize (Subclass)", "\n")
> dots <- list(...)
> cat("\t... =");str(dots);cat("\n")
> .values = integer(count)
> callNextMethod(.Object, .values = .values, ...)
> })
>
> Subclass <- function(count, id = "") {
> new("Subclass", count, id = id)
> }
>
> cat("*** Create class using new() ***\n")
> str(new("Subclass", id = "test0"))
> str(new("Subclass", count = 3, id = "test1"))
>
> cat("*** Create class using generating function ***\n")
> #trace("initialize", signature = "Subclass", browser)
> str(Subclass(count = 3, id = "test2"))
>
> ----------------------------------------------------------
> SIGSIG -- signature too long (core dumped)
>

R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Sat Aug 06 05:21:25 2005

This archive was generated by hypermail 2.1.8 : Mon 24 Oct 2005 - 22:27:37 GMT