Good to know about the method?foo("numeric") syntax. And apparently it knows
about inheritance! Thanks for mentioning that. I see it's documented in ?`?`...
Darn! How could I miss it for so many years!
Note however that this syntax doesn't seem to work in case of "ANY" truncation
so I won't be
Agreed but I'm not sure we want users accessing documentation with those
types of aliases. One option is the method?foo("numeric") syntax.
On Thu, Mar 21, 2019 at 9:52 PM Pages, Herve wrote:
> Fine with me as long as eliminating the inconveniences associated with it
> can be put on the roadmap.
Fine with me as long as eliminating the inconveniences associated with it can
be put on the roadmap. The alias instability and the fact that the user has no
way to know if s/he should do ?`foo,numeric-method` or
?`foo,numeric,ANY-method` to find the method has been a long-standing problem.
H.
If we started over, I'd try to avoid this sort of complexity, but "ANY"
truncation has been happening since at least 2003.
> matchSignature(c("numeric", "ANY"), foo)
x
"numeric"
So I'm not sure we want to mess with it.
Michael
On Thu, Mar 21, 2019 at 8:14 PM Pages, Herve wrote:
> Hi M
Hi Michael,
Thanks for looking into this. I suspect that truncation of ANY suffixes from
method signatures is also the culprit behind the sudden breakage of aliases of
the form \alias{foo,numeric-method} when a method without the ANY suffix in its
signature gets added to the ecosystem. See my p
This is due to the intentional truncation of ANY suffixes from method
signatures. I've hacked selectMethod() to be robust to that and will commit
soon. Thanks for the report.
Michael
On Thu, Mar 14, 2019 at 9:32 AM Pages, Herve wrote:
> Here is an example:
>
> setGeneric("foo", function(x, y)
Here is an example:
setGeneric("foo", function(x, y) standardGeneric("foo"))
setMethod("foo", c("numeric", "ANY"),
function(x, y) cat("I'm the foo#numeric#ANY method\n")
)
Dispatch works as expected but selectMethod() fails to find the method:
> foo(1, TRUE)
I'm the foo#numeric#
