on Tue Apr 19 2016, "Vladimir.S via swift-evolution" <swift-evolution@swift.org> wrote:
> Although I personally don't feel this is right decision(renaming) for > a number of reasons, but the new API Design Guidelines were already > accepted and it seems like nothing can be changed already: > > API Design Guidelines (SE-0023) > https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md > https://swift.org/documentation/api-design-guidelines/ > > It seems like most of us like and support these changes. Even if some > have IMO strong arguments against it. > > So we just have to accept all these mapped/sorted, and following the > API Design Guidelines we just *must* to have *flattened* instead of > *flatten* > > Don't see any possibilities to discuss this. Opinions? Cases like this are exactly why the API guidelines have a “Use terminology well” section. “map” is provided for by that section. > On 19.04.2016 12:30, Thorsten Seitz via swift-evolution wrote: >> 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 >>> <swift-evolution@swift.org>: >>> >>> 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 >> _______________________________________________ >> 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 -- Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
