[swift-evolution] [SR-933] Rename flatten to flattened

[David Hart]

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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution