I couldn't find it, so maybe it doesn't exist, but...

# announcements

[Michael de Kaste]

I couldn't find it, so maybe it doesn't exist, but can I make a generic constraint where something MAYBE extends certain interfaces?

interface Code{
    private val code: String
}

interface Keyable{
    private val key: String
}

fun <T> getThing(obj: T) : Pair<String, String?> where T : Code, T maybe Keyable{
    return obj.code to obj.key //implied that since we're not sure that Keyable is implemented, the field becomes nullable
}

[diesieben07]

I don't think this exists, you would just use (obj as? Keyable)?.key.

[Michael de Kaste]

that's what I did too, but that splits the generic constraint in both function type and function execution. I think that's ugly

[diesieben07]

Well, its not really a constraint if it's not a requirement, is it? 😄

[Stephan Schroeder]

I think you have to write two getThing methods, once that takes a Keyable and one (probably slightly different named) that takes another object. As Kotlin is a statically compiled language, the interfaces of your object need to be known at compile-time not run-time.

[diesieben07]

I am not sure what the difference is between specifying the "maybe" constraint and not specifying it at all...

[Michael de Kaste]

@diesieben07 you're right, it's not really a constraint if we don't know.

It's just that, if the interface becomes bigger it would be unfun to declare as? on the class every time you need one of it's fields haha. (imagine an interface with 10 vals)

just becomes easier to type

[Stephan Schroeder]

good point @diesieben07
how about:

fun <T:Code> getThing(obj: T) : Pair<String, String?> {
    if(T is Keyable) {
    return obj.code to obj.key //implied that since we're not sure that Keyable is implemented, the field becomes nullable
   }else {
     return ...whatever you do if it isn't Keyable
   }
}

There is even smartcasting.

[diesieben07]

Alternatively:

val keyable = obj as? Keyable
// more logic
keyable?.thing

...
keyable?.otherThing

[Stephan Schroeder]

as throws an Exception if the object isn’t of that class, use is!

[diesieben07]

Not as, as?

[diesieben07]

as? returns null if the cast is not possible

[Stephan Schroeder]

as? just means the type can be nullable, it’ll still throw that exception if your object isn’t of that type or null. Use is 😉

[diesieben07]

No.

[diesieben07]

"foo" as? Int is null

[diesieben07]

"foo" as Int? (what you mean) throws exception

[Michael de Kaste]

as? is indeed a safe cast

[diesieben07]

https://kotlinlang.org/docs/reference/typecasts.html#safe-nullable-cast-operator

[Stephan Schroeder]

no, is is the safe cast! but only within the true-case if-block!

[diesieben07]

You are wrong, Stephan 😛 Read the link

[Michael de Kaste]

it as? Int ===

return when(it){
    is Int -> it //as Int smartcast
    else -> null
}

[diesieben07]

Or, on play:
https://pl.kotl.in/Z_LLmSpSI

[Stephan Schroeder]

the block slightly undernies calls as the “unsafe cast” https://kotlinlang.org/docs/reference/typecasts.html#unsafe-cast-operator

[diesieben07]

Yes. "as" and "as?" are different.

[diesieben07]

They are separate operators.

[Stephan Schroeder]

I understand, but is is the one to use here.

[diesieben07]

I disagree 😉

[diesieben07]

That would require you to have completely separate code-blocks for "is instance" and "is not instance". instead of falling back on null, which is what was originally requested.

[Stephan Schroeder]

ah, because you’re fine with obj.key being null, I stand corrected.

[Stephan Schroeder]

I was thinking more generally not in this special case.

[diesieben07]

There is nothing wrong with as?, and it can be very useful.
For example:
val something = (obj as? Foo)?.key ?: "default value"

[diesieben07]

Writing that with is is much more verbose

[Stephan Schroeder]

well, you don’t need a default value here, that’s why as? works but otherwise I’d still go for
val something = if(obj is Fee) obj.key else "default value"

[diesieben07]

well, let's agree to disagree I guess.

[Michael de Kaste]

I'd still write that as

(obj as? Fee).key ?: "default value"

I'm not a fan of onelining an if like that. But mostly because the ternary operator got wrongfully omitted from design (personal opinion)

[Stephan Schroeder]

again, the return type of this function is Pair<String, String?>, so yes,
return obj.code to (obj as? Keyable)?.key is shortest here and the way to go.