Hi all,
What it says in the title. This is likely to cause a lot of CRAN packages
to fail (I can try and quantify this if seen fit), but I think it's for the
best. Packages should not (IMHO) be relying on partial matching in package
code / tests. One might be more permissive for vignette/examples code,
though I still find it poor practice.
Among many reasons why package authors should resist using partial
matching, today I saw this:
upstream package A adds a new argument 'nb' to its print method, now there
are two arguments 'na' and 'nb' starting with 'n'
downstream package B importing A starts failing because it was using
print(n=...) and relying on that resolving to na= but now it's ambiguous
This feels like an unnecessary risk for considerate package A authors to
need to take into account when designing their API. Yes, downstream package
B "should" be broken & resubmitted to CRAN, but (1) there is some perceived
"blame" for package A "causing B to be removed" and (2) the re-submitted
package is by no means assured to be "safe" -- time-constrained B authors
may just fix the minimum set of partially-matched calls while leaving
potentially many other similar at-risk call sites unchanged.
Better to enforce exact matching in package code globally, I think.
It seems likely (given how options work in R) that committed authors will
be able to sidestep the issue by disabling the PartialMatch warnings, but
better to make this inconvenient with a stricter default.
Mike C
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
