Use of enw_ prefix

Developers
2

@adrianlison replied:

Another thing is, tbh, it took me a second to understand that enw stands for epinowcast, and not something like “environment/environmental”. Could be just me however :laughing:

FelixGuenter:

haha no, I was confused by this in the beginning as well :smiley:

@samabbott:

yeah, it is perhaps not the best choice!

@katsherrat:

Hello! As a new user (hoping to contribute), 100% this wasn’t just you @adrianlison !

@samabbott:

Okay, so we are arriving at a census that we don’t like it as is. Can we just drop them?

The big downside is lots and lots of namespace clashes with other packages and non-unique names. Do we still need some of them (maybe with just a different prefix) or can we drop all of them?

For example enw_preprocess_data() → preprocess_data() which is very generic. Similarly all the plotting functions become essentially called variations on plot. we could rename enw_preprocess_data() → preprocess_data_for_nowcasting() or something similar and perhaps there are other instances of this?

The other big offenders are the modelling functions. For example enw_missing(), enw_model((), enw_reference() etc. I feel like a prefix drop is on its own just going to be confusing?

@teojcryan:

I also agree that writing the enw_ prefix every time is slightly confusing if not a bit tedious.

Dropping all of them makes sense, saves the trouble of trying to recall which functions still have the enw_ prefix. Unsure how to deal with the generic sounding functions. Is this where the package::function schema comes in?

@sbfnk:

Personally I prefer having generic names that are qualified by the package name over very descriptive function names, i.e. epinowcast::preprocess_data() over preprocess_data_for_nowcasting, epinowcast::model() over enw_model() etc.

@adrianlison:

Also, we are not a package like dplyr, where you write dozens of lines of code with the same function over and over again. For most use cases, I guess people will just copy the skeleton from one of our vignettes and adapt it, so writing epinowcast::foo() would not put a huge burden on them.

@samabbott:

So you don’t think we should extend to cover all common data tasks (enw_select()) - shocking lack of vision :laughing:.

Right, I am not hearing many people on board with keeping the status quo so unless anyone else is out there (please weigh in) who likes things as they are I guess will start to think about promoting this into an issue.

@pearsonca:

Seems like a few other alternatives here.

Could arrange things such that users could enw::foo(...) via options like those described in namespaces - "import as" in R - Stack Overflow

Could take the S3 approach, and define classes such that foo.epinowcastobj(...) can be invoked as simply foo(someepinowcastobj, ...) for pertinent objects. I understand there are objections to S3, but shrug seems useful for this case.

That second option has some potential benefits integrating into other ecosystems, but that seems pretty marginal unless you’re already aware of those opportunities.