Closed WilDoane closed 13 years ago
I only see two options:
ne
and sw
What am I missing?
Option 2 tends not to be an option in programming.
Option 1 + an adapter would be my recommendation: accept "ne", but then
northeastShift <- ne
early in the code, to adapt the input parameters to your more expressive naming convention.
The adapter proposal is good, but it still means "ne" appears in the signature. (It was something I was thinking of as a option 3, but it seemed identical to option 1 in that when calling the function the user sees no difference from the old granova: the adapter is within the body of the function.
That's the price of exposing a public API. You never want to break code that people have already created.
And, yes, I do worry about the public API. It's hard not to. Anything public runs the risk of not being able to be changed in future releases.
Just for the record here, if granova.ds.ggplot()
becomes the new default granova.ds()
, then:
I think a third option might be to match on as many parameters from the old API as we can, then use . . .
in the function signature as a way to handle any non-matched parameters, even if we might discard them in the function body.
So, a signature like:
granova.ds.ggplot <- function( data = NULL,
plotTitle = "Dependent Sample Scatterplot",
conf.level = 0.95,
plotTheme = theme_granova()
)
Means you could call our function with a legacy parameter (like jj):
granova.ds.ggplot(data = rat, jj = 5)
And the function would take the jj
parameter, but just never use it and otherwise execute normally.
This is the public API. Anyone using the package already would have to change all their calls to granova.ds to use your new formal parameter names.