Thanks for adding a long-name variant! Indeed I feel the code is much more
self-documenting this way. But in the end it is only a matter of getting
used to an API. Power users of "sc" will certainly be able to read the
original short-name variant without problems.
On Thursday, January 27, 2022
I made a second variant in a separate
repo/module: https://pkg.go.dev/github.com/egonk/scr
The function names are more descriptive, Printf wrappers were removed and
it is not meant to be used as a dot import anymore.
On Monday, January 24, 2022 at 12:32:48 PM UTC+1 eko...@gmail.com wrote:
> sc
Good ideas, I added explanations for the
shorthands:
https://github.com/egonk/sc/commit/257d48f5ba187082ffb6a9b8b9d326eca26cb787
W or Wrap comes from the classic errors.Wrap (https://github.com/pkg/errors)
Long forms might be added in a different package in the future (like
github.com/egonk/sc
For my money, as a newcomer to the API, having both the long named function
and the shorthand would be useful. I can see myself using M immediately,
but some like W I'm not likely to remember as readily and longer names
would help in adopting the library. (Also, what is the mnemonic for W?)
Thanks for the feedback! I can't say I disagree and I half expected the
points you mentioned. Out of all the wrappers, P and PE admittedly give the
least value.
I placed more weight on these factors:
- compared to the deployed production code that I'm working with (basically
carved in stone and
Thanks for sharing your package.
To me it seems that the functions are rather shallow wrappers around other
single functions from the standard library (e.g., sc.P() maps 1:1 to
fmt.Printf()). You certainly save a couple of keystrokes while *writing* a
script this way, but on the other hand, *re
