[swift-evolution] What about renaming Optional.map to Optional.mapMe ?

[Daniel Leping]

Totally against renaming. Keeping the syntax consistent is a good practice.
If you have to use Monade inside a Monade - handle it your way. Otherwise
think of flattening to single Monade layer.

I strongly feel we should keep standard naming for functional approach.

On Wed, 7 Dec 2016 at 7:43 Robert Widmann via swift-evolution <
swift-evolution at swift.org> wrote:

> I don't think this is a case where that rule applies, rather it seems like
> we're sliding back into Objective-C's approach of "stick a sentence into a
> selector".  `map` for Arrays is not called `mapIterateApply`, map for Sets
> is not called `mapUnorderedIterateApply`, map for Dictionaries is not
> called `mapUnorderedIterateKeyValuePairsApply`.  In every case, you are
> performing the same essential operation, so why not give them the same
> name?  There is incredible power in being able to pin down a singular
> common concept and factor it out as Sequence has done.  Moreso than not
> omitting needless words here in my opinion.
>
> A certain, shall we say, controversial overload of `flatMap` is a
> different kettle of fish, though.
>
> ~Robert Widmann
>
> 2016/12/06 21:46、Jay Zhao <zhaojianyin at icloud.com> のメッセージ:
>
> It applies in theory to think Optional as a collect of one and for that
> reason map is a perfect name.
>
> But in practice, we often use the same variable name for *array* and
> *array?* .  So when you see :
> cars.*map*({...$0...})
> You can not tell which map and even worse which $0 it is.
>
> According to Swift API Design Guidelines *#1*, *Clarity at the point of
> use*.
> And to combine theory and practice, I propose *mapUnwrapped* to remove
> the confusion.
>
> Actually this is what’s been adopted in my company:
>
> public extension Optional {
>
>     /// Pass the `Optional` into the closure that returns `Non-Optional`
>
>     public func mapUnwrapped<U>(_ transform: (Wrapped) throws -> U)
> rethrows -> U? {
>
>         return try map(transform)
>
>     }
>
> }
>
> To summary my idea:
> This is the situation where usability > design purity for a language(a
> tool).
>
>
>
> On 7 Dec 2016, at 08:05, Robert Widmann <devteam.codafi at gmail.com> wrote:
>
> If you think of Optional as a zero-or-one element collection there's
> really no reason this operation should be named any differently.  It still
> lifts a function over values to one over Optionals.  It still extracts the
> contents of the structure and applies the function (propagating failure if
> necessary).  The operation is no different from the one required of a plain
> Sequence conformance, why should it have a new name if it is not a new
> operation?
>
> ~Robert Widmann
>
> 2016/12/05 22:46、Jay Zhao via swift-evolution <swift-evolution at swift.org>
> のメッセージ:
>
> Hi there,
>
> Code explains everything:
>
>
> /// Maybe a bad API naming in Swift? See below:
>
>         /// array1 can be array of any object that have a `count` method
>         let array1 = [[String]]()
>         let array2 :[String]? = nil
>
>
>         // I believe the confusion between `array.map` and
> `optionalArray.map` is really bad.
>         // Because when you read code like this, you can not tell which
> is which:
>         _ = array1.map({$0.count})
>         _ = array2.map({$0.count})
>
>         // It can be clearer:
>         // 1, we pass `self.element` into the closure
>         _ = array1.map({$0.count})
>         // 2, we pass self directly into the closure
>         _ = array2.mapMe({$0.count})
>
>
> The mapFlat method is also problematic.
>
> Yours,
> Jay Zhao
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161207/633f0cb2/attachment.html>