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 < [email protected]> 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 <[email protected]> のメッセージ: > > 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 <[email protected]> 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 <[email protected]> > のメッセージ: > > 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > > swift-evolution mailing list > > [email protected] > > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
