I still don’t see what’s being lost here, it’s not like the proposal is to
radically rename them, all we’d end up with is .mapped(), .flattened(),
.filtered() etc., which any good search engine should still be able to find,
and will still come up in auto-completion if you start typing .map, .flatten
and so-on. I just don’t see the point of even having naming conventions if we
allow outside influences to force exceptions for IMO fairly weak reasons; it
amounts to the “because everyone else is doing it” reasoning, but again, it’s
not as if someone used to using .map is going to be suddenly lost and confused
when presented with .mapped() instead.
As someone who has been using `map` for virtually my entire programming career, across
languages as different as Perl, Haskell, Ruby, Objective-C (with my own categories) and
now Swift, I would be as surprised by a `map` named `mapped` as I would be by a letter
addressed to "Brented".
The naming exception is simple and principled: When other languages have
universally adopted a given name, and there's nothing particularly wrong with
that name except that it doesn't match Swift conventions, don't fight the trend
just to be different, or just to be self-consistent. People would figure out
`mapped`, sure, but `map` causes not even a moment of confusion.
Do you also think that trigonometry should be `foo.sined`, `foo.cosined`, and
`foo.tangented`? Or maybe `foo.sine`, `foo.cosine`, and `foo.tangent`, with
corresponding `foo.formSine`, `foo.formCosine`, and `foo.formTangent` functions?
Remember the first and most important sentence in the API Guidelines: "Clarity at
the point of use is your most important goal." If there is a universally-accepted
nomenclature for a particular operation, the clearest thing we can do is to adopt it,
even if it doesn't match our normal guidelines.
Consistency is a powerful and satisfying goal, but we must be careful not to be seduced
by it. "A foolish consistency is the hobgoblin of little minds." When there is
a compelling reason to deviate from the guidelines, we should be prepared to do so.*
Consistency in API naming is a means to convey semantics, not an end in itself.
We must not let the cart be put before the horse.
(Besides, since they take arguments, we should favor `mapping`, `filtering`,
`flatMapping`, etc. Or perhaps even `mappingFlattened` for the last one. Can
you see the rabbit hole we're beginning to tumble down?)
* Well, as the people writing the guidelines, we should try to modify the guidelines to
write a general rule accommodating the deviation, because any situation we encounter is
likely to be encountered by others as well. We've done that in this case by writing the
"term of art" rule.
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
