rename hooks
bmeck opened this issue · 14 comments
The names toKey / toValue might be confusing if we ad an identity/equality hook in the future.
Calling these coerceKey and coerceValue likely is acceptable.
toString and toValue coerce already, so I'd say it wouldn't be confusing and that the precedent is very clear; however, coerceKey and coerceValue, or mapKey and mapValue, would both be acceptable to me.
landed as coerce* for now.
coerce seems not very friendly to non-English speakers. I'd prefer toXXX or mapXXX if possible.
They’re all English words, including map and to - why is coerce (a common PLT term) unfriendly?
@ljharb
As my knowledge "coerce" is not a common word in simple english (assume <5000 vocabulary), for example, "coerce" is not in the CET4/CET6 vocabulary (which already include about 8000 words).
Though "coerce" is a common PLT term, it seems it's very rarely been used in API name. At least not in JS.
"Type coercion" is a pretty well-known concept, isn't it? String(3) is coercing a number to a string, for example.
@ljharb Yes it may be a pretty well-known concept, but it doesn't mean the programmers have to know the English word "coercion" for this concept.
I can only tell what most Chinese programmers do. Obviously we communicate with each other mainly in Chinese 😛 , with some technical terms in English. Whether a concept mostly expressed in English word or Chinese translation depends.
As my experience, we rarely use English words "coerce", "coercion", instead we use more general word "转换"(convert) "转型"(type conversion) in the context. Note there is no 1:1 term mapping in this case, for example "casting" could also be translated to "转型".
There may be several factors. As my previous comment, "coerce" is not in the CET vocabulary, which means most Chinese people with bachelor degree (except those major in English) or below have never learn the word "coerce" in school. Use myself as a example, even I know the word "coerce" I just found that I never really sure how to pronounce it 😝 , which prove that I never use it in daily communication before... On the other hand, if a word is used as a keyword or in the API name, the programmers have to learn it and say it in daily communication. Unfortunately "coerce" is not that case, at least not before this proposal.
The other factor, the concept of "coerce" may be not as clear as we thought.
See "What is the difference between casting and coercing?" on stackoverflow.
The top ranked answer say:
coercion is implicit, cast is explicit
As such explanation, String(3) is "casting" not "coercing" 😂 .
The interesting part of it is, the question has tag "C#", and ECMA-335 CLI standard already have official explanation of them, but the top ranked answers still deviate from it.
I think agreeing on a name is fine, @hax & @bakkot could you discuss things since coerce and to seem to be problematic. I don't think I have high stakes in naming personally, but think if terms are seen as confusing we should reopen discussion. We could do normalize, map, etc. the options are many or there could be agreement on one of the existing ideas if we can kick off discussion.
While I'm still not a fan of toKey, if coerce is going to cause more confusion it would not be terrible to end up with toKey. I'd still prefer another name, but wouldn't block over it if we can't find a mutually agreeable one.
In the spirit of suggesting names, how do you all feel about asKey?
I feel toXXX is like coerce and asXXX is like cast, so I'm not sure how asXXX is better than toXXX.
The names toKey / toValue might be confusing if we ad an identity/equality hook in the future
Could somebody first help me to understand the problem of toKey? Thank you.
Could somebody first help me to understand the problem of
toKey? Thank you.
My problem with it is that there are other things that such an operation might plausibly do which we might someday want to introduce into the language.
For example, the first time I saw this proposal I assumed it would work like a combination of the __eq__ and __hash__ methods in Python (or the equals and hashCode methods in Java, or the Hash and Pred type parameters for unordered maps in C++, or the comparer argument for dictionaries in C#): that is, the map would still store the original object (for example when iterating over the collection), but it would use the toKey method to determine how to insert objects into the map for the purposes of determining collisions. I believe this is a much more common capability in other languages than the one in this proposal (and, indeed, one we've discussed adding to JS before), so coming from another language it's what I'd expect to find. But that's not what it does.
I would ideally like to find a name which makes it clear that this operation is not that one: that this is about transforming the user-exposed representation of the data in the map, not just the value used by the underlying data store. I don't think toKey does a good job of that. (Though it may be that there is no unambiguous name.)
Ok, I understand your concern now, but I doubt changing name from toValue to asValue or coerceValue could really solve it (or even worse: they may think it as coerceValueForCompare 😂 )