Channels
#stdlib
- h
hastebrot
04/13/2016, 8:05 AM-.kt - h
hastebrot
04/13/2016, 8:06 AMIn the snippet
is only called onclose()
andinputStream
when usingoutputStream
.use() - h
hastebrot
04/13/2016, 8:07 AMAhh, you want to know if there is a simpler/cleaner way. A
function would be nice.copyToAndClose() - k
kirillrakhman
04/13/2016, 9:43 AMshould
be optimized if any of the two lists is empty?list1 + list2 - k
konsoletyper
04/13/2016, 9:53 AM@kirillrakhman: I guess defesive copy must be created anyway. - m
michaelsims
04/13/2016, 11:32 AM@hastebrot: Thanks, yeah. Just wanted to know if this was idiomatic or if other Kotlin devs would raise an eyebrow - r
rocketraman
04/13/2016, 5:24 PMJDK8 has Optionals and Kotlin has nullables. Simplifying converting between these types would be nice. Should the stdlib include functions like the following: - r
rocketraman
04/13/2016, 5:24 PMOptional_to_nullable_conversion_functions.kt - i
ilya.gorbunov
04/13/2016, 5:33 PMThe first extension has too broad scope: it would be available on value of any type. Generally, we're against such extensions in default packages. - e
evanchooly
04/13/2016, 5:34 PMisn’t that kinda the point for it to be broadly available? - r
rocketraman
04/13/2016, 5:35 PMWell the scope is
, notT?
. Shouldn't that mean its only available on nullable types?T - r
rocketraman
04/13/2016, 5:36 PMThough T is of course
.Any - y
yole
04/13/2016, 5:36 PMno. there is no way to declare an extension function that is only available on nullable types - r
rocketraman
04/13/2016, 5:37 PMMaybe that belongs in #C0B9K7EP2 then? simple smile - y
yole
04/13/2016, 5:37 PMno - y
yole
04/13/2016, 5:37 PMa non-null type is a subtype of the corresponding nullable type - y
yole
04/13/2016, 5:38 PManything applicable to a type would also be applicable to any of its subtypes - i
ilya.gorbunov
04/13/2016, 5:39 PMLimiting the lower bound is a language proposal indeed. We even have an issue for this https://youtrack.jetbrains.com/issue/KT-209 - i
ilya.gorbunov
04/13/2016, 5:41 PMOn the other hand the first one could be a top-level function like:Copy codefun <T : Any> optionalOf(value: T?): Optional<T> = Optional.ofNullable<T>(value) - r
rocketraman
04/13/2016, 5:42 PMYeah that would work - v
voddan
04/13/2016, 9:35 PMA point for it NOT to be imported by default: I use java8 and it happens that I haven't met a singleOptional - r
rocketraman
04/13/2016, 11:09 PMI think that will change over time. The concept is still relatively new to most java developers. Unless everyone just moves to Kotlin of course 😉👍 2 - e
evanchooly
04/13/2016, 11:44 PMwhich they should👍 1 - k
kirillrakhman
04/14/2016, 8:11 AMdidn't Brian Goetz say, Optional is mostly for the streaming API? - m
mikehearn
04/14/2016, 9:08 AMyeah - m
mikehearn
04/14/2016, 9:09 AMthere are debates in the openjdk community about over-use of optional in some new APIs - m
mathiasbn
04/14/2016, 9:09 AMWell I have heard that one too. Or at least that it is meant for API designers in return values. JetBrains also added a warning if you use it as parameter or field. I just don't understand why. I have used it all over for years now (guava pre java 8) - m
mikehearn
04/14/2016, 9:09 AMit's probably the least efficient way to represent optionality you could come up with - m
mathiasbn
04/14/2016, 9:11 AMbut unless you are in some tight inner loop somewhere, the readability and the option to continue your 'pipeline' at optional (or exceptional if you add something like Try) is really nice - m
mikehearn
04/14/2016, 10:52 AMare there any situations in which
is better than what Kotlin has?Optional