Channels
#stdlib
- f
fellshard
03/05/2016, 8:33 AMUnder theory the function could mutate the elements, but that's inadvisable, as is par for the course for such functional patterns. - v
voddan
03/05/2016, 8:38 AMwe may change
to return the collection instead offorEachUnit - v
voddan
03/05/2016, 8:38 AMeven clear naming IMO - v
voddan
03/05/2016, 8:39 AMshould not brake (almost) any code - v
vmironov
03/05/2016, 9:37 AMand by “should not brake (almost) any code” you actually mean “it will break everything because it’s incompatible binary change”? - v
vmironov
03/05/2016, 9:38 AM@voddan: your implementation of
is totally wrong: 1. It will evaluate sequence eagerly 2. It will evaluate sequence multiple times 3. It will apply side effects in a wrong orderpeek - v
vmironov
03/05/2016, 9:39 AMCopy codefun main(args: Array<String>) { val sequence = sequenceOf("1", "2", "3") sequence .peekRight { println("[peekRight] $it") } .forEach { println("[forEach] $it") } println("=".repeat(13)) sequence .peekWrong { println("[peekWrong] $it") } .forEach { println("[forEach] $it") } } inline fun <T> Sequence<T>.peekRight(crossinline action: (T) -> Unit) = map { action(it); it } inline fun <T> Sequence<T>.peekWrong(crossinline action: (T) -> Unit) = apply { forEach(action) } - v
vmironov
03/05/2016, 9:40 AMoutput:Copy code[peekRight] 1 [forEach] 1 [peekRight] 2 [forEach] 2 [peekRight] 3 [forEach] 3 ============= [peekWrong] 1 [peekWrong] 2 [peekWrong] 3 [forEach] 1 [forEach] 2 [forEach] 3 - v
vmironov
03/05/2016, 9:42 AMthe problem with
, it can be easily implemented forpeek
, but not forSequence
orListIterable - v
voddan
03/05/2016, 11:16 AM@vmironov: thanks for the explanation. Actually what you described are not three , but single problem -
evaluates everything eagerly, periodforEach - v
voddan
03/05/2016, 11:17 AMif I understood you correctly,
is a lazypeekforEach - v
voddan
03/05/2016, 11:20 AMnaming is weird - v
voddan
03/05/2016, 11:21 AMit goes from rxJava, right? Can't find
in Scala, Haskell'speek
means something completely differentpeek - v
voddan
03/05/2016, 11:22 AMbtw, it feels that performans of
can be improvedmap {f(it); it} - v
vmironov
03/05/2016, 11:29 AMdo you really want to improve O(1)? - v
voddan
03/05/2016, 12:02 PMit it goes into stdlib - yes, definitely - k
kirillrakhman
03/07/2016, 12:57 PMis there a stdlib function construct a file path from a number of fragments - k
kirillrakhman
03/07/2016, 12:57 PMinstead of nesting a dozen
constructor callsFile() - m
mikehearn
03/07/2016, 1:53 PMlook at the java.nio.file API - m
mikehearn
03/07/2016, 1:53 PMand in particular,
. it's java 7+ so if you're on android, no use.Paths.get() - m
mikehearn
03/07/2016, 1:53 PMbut if you can use 7+ it's a better API - e
evanchooly
03/07/2016, 2:11 PMor just write an extension function - k
kirillrakhman
03/07/2016, 2:38 PMyeah, I'm on Android - k
kirillrakhman
03/07/2016, 2:38 PMI tried, turns out it's not that straight forward - k
kirillrakhman
03/07/2016, 2:39 PMthe
constructor accepts Strings or Files as the first argument, but only Strings as the second argumentFile - j
jw
03/07/2016, 2:40 PMI'd do something like:Copy codefun paths(base: File, vararg pathSegments: String): File { var result = base for (pathSegment in pathSegments) { result = File(result, pathSegment) } return result } - j
jw
03/07/2016, 2:40 PMor make it an extension method onFile - k
kirillrakhman
03/07/2016, 2:41 PMlooks good, thanks Jake - v
vmironov
03/07/2016, 2:48 PMIt can be even simplified to a simple one-liner:Copy codefun paths(base: File, vararg pathSegments: String): File { return pathSegments.fold(base) { file, segment -> File(file, segment) } } - k
kirillrakhman
03/07/2016, 2:48 PMfp ftw