# Use of enw\_ prefix
**URL:** https://community.epinowcast.org/t/use-of-enw-prefix/42
**Category:** Developers
**Tags:** design-choices
**Created:** [23 August 2022 21:09 UTC](https://community.epinowcast.org/t/use-of-enw-prefix/42 "2022-08-23T21:09:06Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@adrianlison](https://community.epinowcast.org/u/adrianlison)
#### Post date: [23 August 2022 21:09 UTC](https://community.epinowcast.org/t/use-of-enw-prefix/42/1 "2022-08-23T21:09:06Z")
Porting the discussion from [here](https://github.com/epiforecasts/epinowcast/discussions/145).
@samabbott wrote
> At the moment we follow some other packages and make use of a prefix for many of our functions. The motivation for this is to avoid namespace conflicts as well as giving the package a clear theme.
>
> However, there is no technical need for this (as it really apes the package::function schema), it takes typing time, and it looks perhaps a bit silly.
>
> It would be a bit of a pain to manage depreciation but not impossible.
---
### Author:  [@adrianlison](https://community.epinowcast.org/u/adrianlison)
#### Post date: [23 August 2022 21:14 UTC](https://community.epinowcast.org/t/use-of-enw-prefix/42/2 "2022-08-23T21:14:44Z")
@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 😆
FelixGuenter:
> haha no, I was confused by this in the beginning as well 😃
@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](https://github.com/adrian-lison) !
@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 😆.
>
> 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](https://stackoverflow.com/questions/24391251/import-as-in-r)
>
> 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.
---
### Author:  [@samabbott](https://community.epinowcast.org/u/samabbott)
#### Post date: [24 August 2022 09:21 UTC](https://community.epinowcast.org/t/use-of-enw-prefix/42/3 "2022-08-24T09:21:56Z")
It looks like we have settled on changing the package naming scheme!
If anyone has some spare capacity we need to promote this to an issue. Ideally this would have:
- Detail of the problem
- Link back to this discussion
- Suggested solution (i.e what needs to be renamed and where)
- List of functions that may need a name change beyond having `enw_` dropped. We can then discuss what these should be
- Suggestion for how to deal with mass function depreciation.