"assume default values are provided."
Ah, no. Choosing to specify or not specify default values is a critical
step. As is deciding where any ... argument will be placed (all specific
arguments after that have to be named when called so positional
compatibility cannot come back to bite you).
"I wonder if it always matters"
That would depend on the relationship you plan to maintain with users of
your package. Still, sometimes breaking changes are necessary for a better
future.
I think the definition of breaking is pretty clear if you are precise in
your argument lists. (R CMD check is very helpful in pestering you to
document your arguments, so you do have the opportunity to be precise in
your API definition.) It is really bad to have silent changes in behavior,
and precision in specification is crucial to avoid that if you distribute
packages.
On September 25, 2019 7:27:25 AM PDT, David Hugh-Jones <
davidhughjones at gmail.com> wrote:
Hi Jeff,
You're right. Indeed, assume default values are provided. I should have
been more precise.
I understand that the positional behaviour has changed. But I wonder if
it
always matters. OTOH I appreciate the force of the idea that an API
change
is an API change, and should be defined precisely.
Best,
David
On Wed, 25 Sep 2019 at 15:01, Jeff Newmiller <jdnewmil at dcn.davis.ca.us>
wrote:
Both of your examples are incompatible.
foo <- function (a, b, c, d, e = NA )
(add with default value) would be compatible.
Your second example cannot be made compatible even with default
because the positional behaviour has changed.
On September 25, 2019 6:51:58 AM PDT, David Hugh-Jones <
davidhughjones at gmail.com> wrote:
Hi all,
Philosophical question. My package follows semantic versioning (
https://semver.org). Incompatible API changes should trigger a major
version upgrade. OK, but what counts as an incompatible change to an
API?
Suppose my current function signature is
foo <- function (a, b, c, d)
and the new one is
foo <- function (a, b, c, d, e)
is that compatible? What if I add an argument, but not at the end:
foo <- function (a, b, c, e, d)
That would be incompatible if people have been calling the arguments
order rather than by name. But sometimes that is unlikely: I doubt
many
people write
lm(y ~ x, mydata, z==3, f, na.omit, "qr", FALSE, FALSE, TRUE, TRUE,
FALSE)
Should I be strict or relaxed about this?
Cheers,
David
[[alternative HTML version deleted]]