image.png

image.png

Oh, would you look at that! Thanks! simple smile

But I've changed opinion, I think it's fine as-is. This is one of those cases where the explicitness is an advantage.

Smartcasting to a type that is't mentioned anywhere?

Absolutely, I wouldn't actually write code like that. But it's a nice example to show smart-casting and sealed classes together.

Of course, given the possibility, some might write code like that. But I wouldn't blame the language in that case. simple smile

For me, I would actually want this to work as I initially expected it to work, but on a case-by-case basis determine whether it would be understandable or not.

I think the explicit

is Cat

is better for when you later add more subclasses to the sealed class. In that case you will get an "when is not exhaustive", instead of a failed smart-cast in the else. And your if (

if (animal is Cat)

instead of

!is Dog

) would still work just fine.

I agree that explicitness here is definitely the way to go as a user of the language. But I find it a little strange that the compiler doesn't understand the

else

cases. So it's more of a question of why it's not supported instead of whether we should do it like that or not. simple smile

If I had to guess it's not supported to encourage proper coding standards 😄

If that's the case, then support for it was explicitly removed?

Why do you say that?

I'm asking. Again, just out of curiosity. simple smile

It’s not like JB dropped the ball here, they saw an opportunity to avoid a unintuitive compile-time error and took it

Understandable. simple smile

Not blaming anyone for anything, btw. I'm just curious as to why stuff is as it is.

What are people here using for a redis client ? Kedis ? Or the less idiomatic Lettuce ?

pretty-print 2.0.0 has been released! https://github.com/snowe2010/pretty-print https://bintray.com/snowe/maven/Pretty-Print/2.0.0 New features: * cycle detection and markers (marks object references that are cycles) * multiline strings with unicode line breaking * a bunch of bug fixes File an issue if you find a bug or think of an improvement I can make. Thanks!

I have been hitting a problem recently with some Java interop:

Parameter specified as non-null is null

. I'm guessing the Java code is not respecting it's own @NonNull annotations and sending a null for a parameter. This is a parameter of an interface definition, so it's an

override fun

in Kotlin, and it won't let me make the parameter in question nullable. What do I do?

Report as a bug to the library. For a temporary fix on the Kotlin side look at https://kotlinlang.org/docs/reference/java-interop.html#jsr-305-support under Compiler configuration.

Yep, going to have to report the bug in the library, for sure. That's a big spec @karelpeeters, is there a way for me to just override the one definition in my interface implementation?

Hmm I don't know how to do that or whether it is even possible either. A quick fix might be to create a new interface in Java that extends the real one with the parameter annotated

@Nullable

.

@karelpeeters Yeah, might have to do that. Will try a few things. Thanks for the clues.

It might be worth creating an issue for.

Possibly. Though, now I'm trying to do this, the Library (which will remain nameless to protect the innocent) didn't make this an Interface, they made it a public abstract static class. But the trick should still apply.

They arn't starting the local terminal in the working directory they are starting it in

/home/jakob/.local/share/JetBrains/Toolbox/apps/Goland/ch-0/191.5532.53/bin

Trying_to_learn_generics_in_Kotlin.kt

So the code above have two problems. 1: The method signature for invoking the rule is pretty nasty with three generic type arguments. 2: In the run method of the RuleExecutor the compiler can't seem to be able to figure out that input is an instance of InputClazz and output is an instance of OutputClazz

Is there a way to restrict the implementers of an interface to be of a certain sub-type?