kevinmost
08/15/2017, 6:40 PMagomez
08/15/2017, 10:06 PMjoshuaavalon
08/16/2017, 8:59 AMdragas
08/16/2017, 10:02 AMthis::method
actually leaking when called in init
or constructor
blocks?diesieben07
08/16/2017, 11:24 AM@JvmSuppressWildcards
annotation like so: List<@JvmSuppressWildcards List<String>>
.roberto.guerra
08/16/2017, 1:34 PMkotlin-stdlib-jre8
always include kotlin-stdlib-jre7
, and if so, does it do any harm to use excludes
to leave out jre7
from the runtimeClasspath
?
runtimeClasspath - Runtime classpath of source set 'main'.
+--- org.slf4j:slf4j-api:1.7.22
+--- org.jetbrains.kotlin:kotlin-stdlib-jre8:1.1.4
| +--- org.jetbrains.kotlin:kotlin-stdlib:1.1.4
| | \--- org.jetbrains:annotations:13.0
| \--- org.jetbrains.kotlin:kotlin-stdlib-jre7:1.1.4
| \--- org.jetbrains.kotlin:kotlin-stdlib:1.1.4 (*)
Ruckus
08/16/2017, 8:51 PMval filtered = (0..list.lastIndex).asSequence()
.filter { it in indexes }
.map(list::get)
.toList()
(I haven't tested it)lab
08/16/2017, 9:18 PMList<AppModel>
(AppModel store all necessary info of an Android app). Here's the getLeaves
method that I'm testing around with:
class WakeTrieNode (val key: Char?,
val value: AppModel?,
var isLeaf: Boolean,
val children: MutableMap<Char, WakeTrieNode> = mutableMapOf()) {
fun getLeaves(): List<AppModel>{
return if (isLeaf && value != null) listOf(value)
else children.flatMap { child ->
child.value.getLeaves()
}
}
}
Is there a better way to do this? The part where it return listOf(value) seems bad to me.karelpeeters
08/16/2017, 9:45 PMcontains
checks for an exact match, so it doesn't really fit your use case.pniederw
08/17/2017, 6:47 AMtschuchort
08/17/2017, 11:39 AMabstract class A<T : S> : T
where T
is an interface?jamieadkins95
08/17/2017, 1:27 PM@Parcelize
class ExampleClass : Parcelable {
var id: Long? = 0
var name: String? = null
var tagName: String? = null
var enabled: Boolean = false
Do my properties have to be constructor parameters?santiago
08/17/2017, 6:10 PMskennedy
08/17/2017, 9:30 PMval X = blah()
and
val X
get() = blah()
agrosner
08/17/2017, 10:16 PMhorse_badorties
08/18/2017, 8:32 AMfun foo(bool: Boolean = true, string1: String) {}
fun main(args: Array<String>) {
foo("b") // does not compile
}
mkatie
08/18/2017, 10:55 AMmilorad
08/18/2017, 11:04 AMit.Specification?.let {
with(it) {
val mk = (make ?: "")
val md = model ?: ""
"$mk $md"
}
}
silas.schwarz
08/18/2017, 11:13 AMkarelpeeters
08/18/2017, 1:27 PMe.lislebo
08/18/2017, 1:40 PMnickk
08/18/2017, 1:51 PMPaul Woitaschek
08/18/2017, 2:25 PMbloodshura
08/18/2017, 7:29 PMSystem.getProperties()
-> System.properties
)?bamboo
08/18/2017, 7:31 PMdumptruckman
08/19/2017, 2:39 AMbillf
08/19/2017, 11:09 PMprivate val df = SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS zzz")
private val value = TimeWithZone(df.parse("2017-08-18 17:25:26.632 PDT"))
@Test fun testDeserialization() {
println("deserialize gives " + deserialize(json))
assertEquals(value, deserialize(json))
}
This failed with a ginormous stack backtrace, deep in the bowels of reflection, telling me it couldn't find a field of TimeWithZone. The fix is compact enough:
println("deserialize gives " + deserialize<TimeWithZone>(json))
OK, so in the assertEquals, type inference is used to make the call of deserialize<Any> into a call of deserialize<TimeWithZone>, whereas in a println, it's not. Reasonable enough, I guess, but a little non-obvious. Intuitively, I just don't expect an expression to change meaning based on where it's used.
In this case, I'd actually rather that type inference hadn't made the assertEquals call work, and instead had forced me to type deserialize<TimeWithZone>(...) in the first place.
I'm sure there's a case to be made for the more eager type inference that Kotlin has today, but I just thought I'd throw this out there as maybe an unintended and undesirable side-effect. I could see this behavior causing a lot of confusion, particularly for someone coming from a less statically-typed background.marcinmoskala
08/20/2017, 3:56 PMclass A {
@get:Arg val a: Int by BoundToValueDelegateProvider()
}
Inside provideDelegate
I have property reference
operator fun provideDelegate(
thisRef: Any?,
prop: KProperty<*>
): ReadWriteProperty<Any, T> {
val annotation1 = prop.getter.findAnnotation<Arg>() // This is null
val annotation2 = prop.javaGetter?.getAnnotation(Arg::class.java) // This is null too
// ...
}
It this bug or expected behavior?muralimohan962
08/20/2017, 4:11 PMltm150895
08/21/2017, 12:13 AM