stri_opts_collator(...)

[hadley]

The documentation for stri_opts_collator says that "any other arguments to this function are purposely ignored". This seems like a deliberate design decision, so I was wondering if you could explain why?

The obvious downside is that misspellings are silently ignored:

stringi::stri_opts_collator(normalisation = TRUE)
#> list()

[gagolews]

The arguments to this function are passed - most frequently - via ... from other routines, whose themselves might be extracting some meaningful actual parameters from ellipsis. In this workflow, stri_opts_collator is just a piece of the puzzle and takes care only of those arguments that it can understand, letting other functions be customized too.

However, that normalisation could be adopted as an alias of normalization seems like a good idea.

[hadley]

Ah ok, that makes sense. Do you have a concrete example I could look at? I'm working on documenting common ... patterns and this would be a nice case study.

It might also be worth considering ellipsis::check_dots_used() to make sure that every argument to ... is used somewhere.

[gagolews]

If something glamorous come to my mind, I'll give an example.

But isn't this what most graphical (I mean, good-old graphics package-based) functions do? print.default takes a ... argument, calls box, axis, and stuff, and these underlying funs take what they need (and understand) from the arg list

[hadley]

I meant a specific example to look at in stringi; doesn't need to be glamorous!

Yes, it's a common pattern in base R, but I think it might be an anti-pattern:

mean(1, 2, 3)
#> [1] 1
weighted.mean(1:3, wt = c(1, 0, 0))
#> [1] 2

^{Created on 2019-03-13 by the reprex package (v0.2.1.9000)}

[gagolews]

Yeah, and:

> sum(1, 2, 3)
[1] 6
> mean(1, 2, 3)
[1] 1

[gagolews]

Hmm... maybe stri_opts_collator (and similar funs) doesn't need to ignore the un-known args after all... I need to take a deeper look at this.

[gagolews]

Okay, I've studied the functions that pass their arguments to stri_opts_* and cannot really justify the existence of the ... parameter here. I'm pretty sure that I have something in mind when I was designing these a few years ago, but time has passed and, oh, well.

I've now marked all ... as deprecated in stri_opts*. They are scheduled for removal in some future version of the package. For the time being, they'll give a warning.