Add 'get_dotenv/3' and 'fetch_dotenv!/2' - #33
Conversation
These wrapper functions provide idiomatic naming that mirror the behavior of `System.get_env/2,3` and `System.fetch_env!/2`. Names were chosen to avoid collision with the `System` function names.
|
Hello, sorry to bother you about this. Just trying to gauge if there is any interest in this PR? I know you're probably busy, but if you could give a brief reply on your level of interest (even just a single word), that would help a lot. Intrigued? Disinterested? Confused? Disgusted? Please, let me know! Thanks, and sorry for harassing you again. |
|
If clarity is a concern, I think We don't necessarily need to import the module, and can use the namespaced function calls. |
|
Dotenvy uses That being said, I'm not dead set on my specific choice of function names. Conciseness is definitely a plus, since it keeps the config file shorter (those extra chars can really add up). |
These wrapper functions provide idiomatic naming behavior that mirrors that of
System.get_env/2,3andSystem.fetch_env!/2.I added these because I was often getting confused between the different
Dotenvy.env!functions (which one to use, and when), and harmonizing them against the style used by System get_env/fetch_env! built-ins made a lot of that confusion go away from me.Names were chosen to avoid collision and confusion with the built-in
Systemfunction names, since Dotenvy is conventionally imported inconfig/runtime.exsinstead of being aliased. This allows a new reader to know that the imported function is a Dotenvy env getter (e.g.get_dotenv/3) at a glance, not the built-in System one (e.g.System.get_env/3).This pull request does not replace or remove any existing functionality, but instead extends it for the sake of improved (in my opinion, at least) ergonomics.
The changes are summarized by the addition made to the cheatsheet:
Thanks!