RC feedback: rename `parse`/`stringify` to `parseToml`/`stringifyToml` about deno_std HOT 7 CLOSED

There seem no consensus on this move.

Also the core team is against this change as the scope of implication of this change is too large and unclear.

Let's not do this.

from deno_std.

I'm slightly against it because to be consistent we would probably have to change many other functions all across Std such as regexp/escape to regexp/escapeRegexp, html/escape to html/escapeHtml, msgpack/encode to msgpack/encodeMsgpack, SemVer functions and so on. If we did that to the entire Std, I think it might feel too verbose in the end.

from deno_std.

I'm a bit indifferent about this, but have these additional considerations/points:

• There is also dotenv & semver (possible others) that have similar method names in their respective modules. Does this mean we would also change these to be consistent?
• Of the listed ones, I've found myself aliasing the import name anyways since parse/stringify is not very descriptive or sometimes collides with a function I've written or import.

from deno_std.

I'd say yes because one would need to alias the import names if importing from multiple packages.

from deno_std.

What would be the reason to do this?
I think putting the mod name into the function name is a slippery slope because one would also need to consider renaming other or even all exported functions of a module to be consistent. Putting the mod name into the function name seems redundant to me. Multiple same name imports can easily be solved with import aliases or * imports.

from deno_std.

I suggest the inverse: keep stringify() and parse() and remove words from APIs that could be seen as overly verbose (within reason). Most APIs within the codebase already adhere to this convention (see list below). However, as already pointed out, far more APIs would need to be adjusted to apply the issue's initial suggestion, which would be very disruptive. Using named imports in the appropriate cases is fine and, to me, is a non-issue.

List of all public function names in the codebase:

https://gist.github.com/kt3k/b387e7faf08ac7170384688261055e6a

from deno_std.

This seems kinda analogous to the Deno philosophy of using actual web platform APIs rather than inventing APIs.

In this case, the similar philosophy would be to encourage the use of the actual JavaScript language feature (import aliases) rather than inventing something to avoid using it.

from deno_std.