[swift-evolution] [SR-933] Rename flatten to flattened
dabrahams at apple.com
Tue Apr 19 18:00:43 CDT 2016
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)
> 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
> 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.
>>> 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
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>> swift-evolution mailing list
>> swift-evolution at swift.org
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution