Rename HTTP::Params.from_hash to HTTP::Params.encode and add an overload for NamedTuple

[jhass]

Also allow passing NamedTuple to the corresponding post_form overloads
on HTTP::Client

That should make passing some static form data (or even some data with static keys) more pleasant without sacrificing on performance as much.

[luislavena]

Format check failed, I believe spaces are required on type unions (Hash | NamedTuple)

[jhass]

Thanks, got a bit rusty I guess :)

[RX14]

.from seems like a little bit of a weird name to me. Maybe .of? That's a little bit weird too i guess. 🤔

[luislavena]

@RX14 I find .from to be consistent with others:

• json: .from_json
• yaml: .from_yaml
• crystal-db: .from_rs

I think in this case, _hash and _tuple are implicit and described by the parameter given to the method call.

[RX14]

@luislavena The consistency between them is that they have the type it's coming from in the same. They sound fine, from on it's own feels weird to me. Why not 2 seperate methods: from_hash and from_tuple?

[asterite]

What about new?

[jhass]

Both of and new even stronger hint at returning an instance of HTTP::Params, while it returns String.

How about we overload build instead?

[asterite]

Oooh... I thought it returned an HTTP::Params. I don't know of a good name, then. Maybe to_s.

[jhass]

Or just encode?

[bcardiff]

Maybe we should restrict to Hash(String, _). I know it isn't part of the initial PR intent.

If we want to work with any type of hash we can merge the implementation.
If we want to support only String key hashes we could restrict here and catch the compile time error sooner.

Hash(String, _) sounds fine to me.

[jhass]

Alright, added the more specific restriction.

[Sija]

Is this PR GTG?