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
R developers,
Seems I get a bad result ("%#4.0-1e" in particular) when trying to use
prettyNum digits=0 with scientific notation. I tried on both my Linux box and
on an online R evaluator and saw the same problem, so it's not limited to my
box at least. I see the problem in both R 3.5.3 and R 3.
