Open RiskoZoSlovenska opened 2 years ago
If I am to throw in my two cents, I personally prefer only having encode()
/decode()
- their names are similar and obvious, and the lack of aliases reduces confusion.
I've started with this in ba42b05, and I agree with using encode
/decode
over stringify
/parse
as it makes the link between them more obvious
Keeping only encode
/decode
may be a challenge with the json
module, unless we want to not offer an unmodified copy of dkjson
like 2.x does.
What happens to json depends on if we add a better json implementation in luvi itself (like cjson)
Luvit 2.x's
json
module provides the functionsstringify()
andparse()
as aliases to theencode()
anddecode()
functions. Node.js'squerystring
module does the same (technically, the latter are aliases for the former), but Luvit'squerystring
function only definesstringify()
andparse()
. Luvit 3.0 would be a good time and place to decide what to namejson
's andquerystring
's functions - whether to provide both sets, or just one.