Totally agree with Brent, too. And I wouldn't rename flatten either. -Thorsten
> Am 11.04.2016 um 08:03 schrieb David Hart via swift-evolution > <[email protected]>: > > 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 > <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
