RFRFC remove `hash` from the Ember lexicon

[chancancode]

This is specifically talking about calling "map/dictionary" objects as "hash", not about "hash location" in the router.

Problems:

• hash is probably a Ruby-ism that we inherited, which makes little sense in our JS context
  • aside: hash in ruby refers to the fact that it is implemented as a hash table, however, I believe the more common name for the abstract data type (i.e. decoupled from the implementation) is a map, dictionary or associative array..?
• In JavaScript, it is probably more common to refer them to just as "objects" (the "o" in "POJOs")
  • a Map is also a thing in modern JavaScript, but it's not what the hash helper produces (maybe it should? probably not? unknown.)
• A straw-man proposal is to rename the hash helper to obj or object, and (maybe later?) deprecate hash
  • We should provide a codemod
• What should we call the second argument passed to helpers? The current signature is commonly referred to as "params and hash", and that's the name/identifier we generate for the function parameters in the blueprints. "options"? What about "params", do we want to rename that too?

[rwjblue]

What should we call the second argument passed to helpers?

IMHO, we should call them positional and named...

[dgeb]

I would favor transitioning from hash to obj if the fn helper lands in #470 (since they seem analogous).

[bertdeblock]

Does renaming params and hash in the helper blueprint need to be part of an RFC or is that something we can just do as is? In the Helper Functions guides we also use the term args instead of params.

[rwjblue]

I think that we can change the blueprint argument names independently of a discussion around the "hash" helper.

[wagenet]

I'm closing this due to inactivity. This doesn't mean that the idea presented here is invalid, but that, unfortunately, nobody has taken the effort to spearhead it and bring it to completion. Please feel free to advocate for it if you believe that this is still worth pursuing. Thanks!