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

[Dave Abrahams]

on Tue Apr 19 2016, "Vladimir.S via swift-evolution" <swift-evolution at 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 at 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 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
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Dave