Skip to content
Prev 2038 / 63421 Next

R's UseMethod() does not dispatch on changed class() (PR#167)

I've done some editing to get things together (hopefully without
changing the semantics)
On Thu, 15 Apr 1999, Prof Brian D Ripley wrote:

            
Now, with my reading, the method will see the argument as it would
if the users call had been directly to the the method, coupled with
the later comment (top of p. 469) that for NextMethod you must take local
bindings for the arguments, yields
   with UseMethod you don't take local bindings, the method gets what
the generic did, but it will rematch (argument names and positions
may have changed). That means you need to ignore what happened
inside of the generic.

  Now, we have the variable definition problem raise it's head,
  UseMethod("foo")
  UseMethod("foo",x)
  If the second version doesn't use the local binding of x then
 UseMethod behaves differently, in terms of how it treats its arguments
 than every other function (which is ok, we just need to be specific
 about it).
  So we have to make a decision, UseMethod does what S does (which is
 fine) or it doesn't.
The standard argument matching system takes over. If there was an
argument y=blah, in the ... then it will get matched to y in foo.lm
even though something different was matched to x in the call to the 
generic. I don't believe that a reevaluation takes place in either 
situation. If x was evaluated and that is what is matched then we
look in the value side of the expression, see that it's there and
carry on. If we match to something new then the standard rules take
over.
  Promises are basically cells with three slots, an unevaluated
expression, an environment in which to carry out the evaluation
of that expression and a value. When we want a value, we look in
the value slot first, if there is no value, we evaluate the
expression and stick the value into the value slot. So promises
should never be evaluated twice.

 For those not bored, here is a difference between R and S that 
we may not want.
bar<-function(w,...) {
    UseMethod("bar")
  }
 bar.foo<-function(y, w) print(w)
x<-30
class(x)<-"foo"

Now in R,
[1] 10
[1] 30
attr(,"class")
[1] "foo"

Notice that if the arguments are not named we use default matching and
that the symbolic name for the first argument in the generic is not
carried over.

In S bar(x,10) and bar(x,y=10) both evaluate to the same thing,
[1] 30
attr(,"class")
[1] "foo"
it appears that the name w has been applied to the first argument and
that is carried with it for subsequent evaluations.

  I'm not sure what you meant by "the change of name causes reevaluation,
when I try
I get,
[1] 31
attr(, "class"):
[1] "foo"
[1] 31
attr(, "class"):
[1] "foo"
  which is only one evaluation (and the same in R)
Change to your hearts content. I think we want something that works
and that makes sense.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._