I hope the codebase im working on succeeds

I just published some work in progress with kotlinjs : https://github.com/ylemoigne/reactKT and https://github.com/ylemoigne/reactKT-material

I will release to Maven central very soon

@natpryce: Use kobalt to build hamkrest and pushing to bintray is trivial simple smile (nice job on Hamkrest by the way)

Cheers. I’ll take a look at kobalt.

@natpryce: Nice work! Looks much more neat than scala's. Don't forget to add it to https://kotlinlang.org/docs/resources.html

@voddan: You mean the

should()

"extension function" in ScalaTest?

Have the Kotlin team considered a way to “hide” properties / functions requiring a higher visibility because of inlining? Some sort of annotation would be helpful: e.g. in

class Foo(@Hide(Visibility.PRIVATE) val a: Int) { inline fun bar() = a }

would generate a warning / error if attempting to access

Foo(5).a

but still allow inlining

fwiw I’m not sure if this is technically possible, or what the implementation limitations would be (java interop might have to expose it, but as

@Deprecated

?)

Apropos testing in Scala. Expecty (power assertions for Scala) looks nice. Unfortunately we can't overload

==

or

equals()

for any type in Kotlin, because the type's already defined

equals()

member always wins.

For something like this:

fun main(args: Array<String>) {
    expecty {
        12.3 == 23.4
        "foo" == "bar"
    }
}

class Expecty() {
    fun Any?.equals(other: Any?): Boolean {
        println("expecty: $this")
        return true
    }
}

fun expecty(context: Expecty.() -> Unit) {
    Expecty().context()
}

I’m not keen on that kind of implicit magic. I prefer Kotlin’s tendency towards explicit composition.

Knowing that the meaning of == cannot be changed for a type is a good thing IMHO

@natpryce: You are right. Also error descriptions with

expecty()

are not as readable as with Hamcrest/Hamkrest.

Was there a plan to llvm compiler for Kotlin ?

some day maybe

https://kotlinlang.slack.com/archives/general/p1447347715000079 @damian: we actually have such property in stdlib: ASSERTIONS_ENABLED https://github.com/JetBrains/kotlin/blob/master/libraries/stdlib/src/kotlin/util/AssertionsJVM.kt#L9 For now we prefer just deprecating it, although it requires to suppress warning on its legal usages in inline functions.

@ilya.gorbunov: Ah, interesting. I don’t mind adding the suppressions for legitimate cases, so this works for me. Thanks simple smile

Great, looking forward to it.

@hastebrot: I actually meant scala's "Parser Combinators"

then use “the hard way” 😉

Class.forName(“foo.bar.Whatever”).newInstance()

requires a no-arg c’tor of course

thx Yann, i did try googling the same thing just under kotlin, didn’t even cross my mind to search under java duh

It’s horrible the null handling… We can’t just pass nullable string to non-nullable api without thinking about what to do if things go wrong… It’s the end of GoodOldCrashableApp ...

sorry, quick reminder because I can't find it in the docs

there are closed classes in Kotlin, if I remember correctly

as in, an abstract class that's inherited only by some other classes defined close to it, an no more