Am 11.04.2016 um 08:03 schrieb David Hart via swift-evolution <swift-evolution@swift.org>:
Totally agree with Brent, map/flatMap are terms of art.
On 10 Apr 2016, at 23:11, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
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