I'd like to have enum inheritance to simulate the enum in C

right now I have to explicitely write down for each enums I have:

Int.xor(enum)

,

enum.xor(enum)

,

enum.xor(int)

, repeated for

or

,

and

,

has

,

hasnt

,

wo

..

with inheritance, I could have a base class handling all this shit

Actually https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-enum/index.html

On the JVM, the EnumSet class implements this.

An enum type represents an individual value from a set, EnumSet represents a set of those values

w00t

Does anyone know if there is something like JvmOverloads for local declarations? item and empty can receive null from JavaFX. When I run this, I get Parameter specified as non-null is null I tried putting on JvmOverloads and making the arguments ?, but the compiler gave me an error about JvmOverloads not being available to local declarations.

@diesieben07 commented on @carlw’s file https://kotlinlang.slack.com/files/U25U0KPFT/F6XM203LY/overriding_a_javafx_api_method.kt:

JvmOverloads

is for functions using default parameters. Just marking the parameters as nullable using

?

is enough.

@carlw commented on @carlw’s file https://kotlinlang.slack.com/files/U25U0KPFT/F6XM203LY/overriding_a_javafx_api_method.kt: thx for replying. That gives me a compiler error on the overrides "updateItem overrides nothing"

@carlw commented on @carlw’s file https://kotlinlang.slack.com/files/U25U0KPFT/F6XM203LY/overriding_a_javafx_api_method.kt: override fun updateItem(item: String?, empty: Boolean?) { // -> compiler error

@diesieben07 commented on @carlw’s file https://kotlinlang.slack.com/files/U25U0KPFT/F6XM203LY/overriding_a_javafx_api_method.kt: Ah, you need to change the type parameter to

String?

as well, since

updateItem

takes a

T

. So in your case

T

is

String

.

In case you’ve been considering attending KotlinConf - we’ve just added a pre-conference workshop and community event on the 1st. If you’re new to Kotlin, the workshop will be ideal to get you up to speed for the conference! https://goo.gl/un5zeV

Hello, I'm creating a JavaFX application base with Gradle, Kotlin and Dagger 2 and I'm trying to get kapt to figure out my ApplicationComponent, but all I'm getting is this warning from gradle:

w: [kapt] Sources output directory is not specified for app_main, skipping annotation processing

. How do I specify a sources output folder? I've done some Android programming previously and never had this problem, although this time my gradle project has multiple modules and no root project sources. Edit: nvm, found a working fix from here: https://github.com/griffio/dagger2-kotlin

what do you think is more readable/natural when it comes to flags 1)

flags has property

2)

property in flags

I am really not convinced by the NPE problems argument. 1. I have rarely if ever had a Java program blow up due to NPE. 2. Kotlin's protection from NPE ends whenever you use platform types. Those are not solved satisfactorily IMO.

var res = someJavaFuncThatActuallyReturnsNull()
// res is now SomeJavaType!
// at this point I can start passing 'res' around and later access anything on it and get an NPE, Kotlin didnt help at all

57 replies It would be nice if Kotlin warned you when when assigning platform types to non-null properties. Like for example:

class ExampleActivity : Activity {
    lateinit var array: IntArray

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        array = intent.getIntArrayExtra("array")
        // throws IllegalStateException: getIntArrayExtra("array") must not be null
    }
}

KotlinConf – New Workshop and Community Event by JetBrains and Realm KotlinConf is just around the corner, and if you haven’t checked out the great speaker line-up and sessions, you might want to do that now! We’ve got two days jam-packed with content around Kotlin, whether you’re doing mobile, desktop, server-side … Continue reading →

Hey, are there any downsides of

inline

functions except disk usage? Why not

inline

(almost) every function?

There are differences.. maybe not downsides. For example, "return" in an inline doesn't do exactly the same as in the non-inline equivalent.

And lambdas are evaluated in a different order

inline to reduce allocation for things like lambda parameters or for reified generics, not just because you think it'll be faster. on the JVM you're probably making it worse since common code invocations are not tracked together anymore and thus won't be compiled as aggressively

That sounds like something that could be interesting to profile next time someone wants to write a "Kotlin's hidden costs" type of article

inline's are good to avoid unnecessary context changes in some languages, if you don't know how a compiler works just forget about it, if you still want to use do it in small methods

We profiled it. For some inline depth it makes no difference, since JIT and Kotlin here doing more or less the same work. Sometimes JIT can be slightly better, sometimes Kotlin. But after some amount of (inlined) code it starts to degrade, mostly because JIT stops doing some optimisations because of the code size, complexity of resulting control flow graphs, etc, etc.

Here is for JVM JIT, not Android.

there's also API implications for inline. you've lost encapsulation and the ability to change that method in a backward compatible way without all your downstream consumers re-compiling

Not really, Kotlin doesn’t allow you to use private function in a public inline function, just for this reason.

sure but that doesn't prevent code from being copied into callsites which you might want to reserve the right to change

it breaks encapsulation of the method, not the entire class