Totally agree with Brent, map/flatMap are terms of art. Sent from my iPad
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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
