Feature request: allow mixed `class = ` and `object = ` arguments to `method()`

[dgkf]

I'm currently trying to mimic the behavior of convert(), where an argument is interpreted literally as a class for dispatch. From what I can tell, this isn't possible currently -- at least not in as rigorously as convert. The best I can come up with is to catch all the calls and then dispatch on a specialized S3 class names. But this leaves quite a lot to be desired.

Nevertheless, I think the current implementation is nearly capable of this type of dispatch.

To support this, I think a minor change to method would make this feasible. method() currently accepts a signature from classes, or a signature from objects. To implement non-standard dispatch like we see in convert(), we'd want a mix of class and object arguments.

If this was allowed, I think convert could even leverage this instead of requiring its own specialized internal method_ to handle this dispatch.

convert <- new_generic("convert", c("from", "to"))

method(convert, list(class_any, class_any)) <- function(from, to, ...) {
  # non-standard dispatch, using to argument as class for dispatch
  dispatched_method <- method(
    convert, 
    class = list(to = to),  # use `to` class for dispatch
    object = list(from = from)  # but `from` object
  )

  dispatched_method(from, to, ...)
}

Of course the exact syntax is up for debate, but hopefully this communicates the idea. This would allow us to pick up the class to and use it directly for dispatch, while using the object, from.

[lawremi]

I've felt the need for this and instead took a prototype-based approach, through zero-arg construction of to. However, while supporting zero-arg construction is generally considered best practice in OOP, it can be awkward in some cases.

It would help to understand your specific use case.

[dgkf]

The impetus was rather trivial - I'm evaluating a string that should produce an R value that adheres to a class. To enforce the class policy, I pass it through convert(). Can share the code once I tidy things up a bit more.

This works for almost everything, but fails when I parse a double ("1") that should be marshaled into an integer.

convert(<double>, class_integer) isn't implemented, which is perfectly sensible if the goal of convert is to only implement lossless type conversions. I didn't want to implement it myself since neither the generic nor any type in the signature is specific to my application. (is there a way to not register specific methods?)

So to patch over this limitation, I added a internal generic that falls back on convert, but allows me to layer on my own internal methods. To implement a poor-man's convert dispatch mechanism, I dispatch on an S3 object with a class name from S7:::class_desc. In my case, I can't simply assume that I can instantiate a 0-arg prototype because I need to support base classes. This works, but it's clunky.

[hadley]

If you have the object, can't you find the class and then pass that, along with the other class, to method()?

[dgkf]

If you have the object, can't you find the class and then pass that, along with the other class, to method()?

Maybe this is a silly question, but how would one do this?

I started down that path, but couldn't find a way to reliably get a class in the way that S7 would use them for dispatch. I got hung up specifically on the case of base classes, but I'd also need to handle other non-S7 types and discover the appropriate S7-ified class descriptor.

[hadley]

Ok, if that's hard now, I think fixing that would be a simpler path to resolving that problem, rather than substantially complicating the API of of method.

[dgkf]

Yeah, I agree - that's the more intuitive interface. If such a function existed, would method() even need an object argument? Maybe there are some performance benefits for keeping it?

Anyways, I created a separate issue for it over in #559