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

Reply via email to