Does Kotlin have an equivalent of the new Java fea...

# getting-started

[poohbar]

Does Kotlin have an equivalent of the new Java feature:

if (obj instanceOf String myString) {
  // myString
}

I know I can do as and get a smart cast but I can’t give it a new name in Kotlin, right?

[Vampire]

The point is, you don't need to give it a new name, you can just use the same smart-casted name.

[poohbar]

giving it a new name improves readability actually.. see this case:

Object obj = "hello";
if (obj instanceof String string) {
    // work with 'string'
} else if (obj instanceof Integer integer) {
    // work with 'integer'
} else {
    // throw
}

[Joffrey]

If you give a proper name for the object in the first place, it is still the same thing after the smart cast so it has no reason to have a different name. Your example is not a real life example, it has no semantics, so we can't really judge from it. Do you have an example where a new name actually improves readability?

[Robert Williams]

If you're doing enough that readability is an issue surely that's a sign that you should extract it?

when (obj) {
is String -> handleString(obj)
}
...
private fun handleString(newName: String) {
// work with 'newName`

[Vampire]

Also including types of things in the names of things is rather bad practice.
That's like calling a variable iNumber to signal in the name it is an int. 🤢
Otherwise as the others said, give the overall variable a proper name that is handy in all branches or extract methods.

[poohbar]

Yeah so the proper name in my case is stringOrInteger. I think we could also just say Java’s feature is more convenient in this specific use case.

[Vampire]

Well, you can say that and we can all disagree to that. 😉
stringOrInteger an equally bad name as iNumber.
The types should not be part of the name, the name should express semantics.
For example input or argument or parameter or whether matches your case.
That's what Joffrey meant when he said that your example is too generic and not a sane real-world use-case. 🙂

[Ruckus]

Without more context, a name like stringOrInteger is usually a pretty terrible name. It gives you no semantic meaning as to what the value is meant to represent (unless you are effectively designing your own type system, but even then, I have a hard time seeing how a type of "string or integer" is remotely useful).

[sreich]

i agree. more context needed. also if you reallyy wanted to go down that rabbit hole you can just do .let { stupidName -> }

[PoisonedYouth]

I can only support the arguments of the others here, variable name should describe the purpose, not type.

[poohbar]

I am surprised none of you can imagine any use case where the new name for the smart cast is useful.

Just to give more context. I am literally writing a CSV output processor that is completely agnostic of any “purpose” and can get strings/numbers as an input. The type literally is the only thing I know about the value. Sure I could also call it input or value.

Even then, it is just nicer in Java where I can start by calling it a value and in the smart casted branches I can call it numberValue or textValue.

If you still don’t see how useful this feature can be then I don’t know what else to say. I am a bit disappointed at how “radically” you folks had to express your “correct” opinion but oh well.

[poohbar]

I will admit that in Java I have ran into cases where the need to come up with a new name just to enable the smart cast was a bit annoying because there was no better name. So it cuts two ways.

Kotlin would probably be flexible enough to make the new name optional so I just thought it’d be a cool feature.

[Vampire]

Noone here was radical or tried to enforce their opinion as "correct" upon you.
We just have a different opinion from what you have shown and you should respect that instead of now starting to attack us, calling us radical and so on.
If you think it is a cool feature, suggest it to the language committee and see what they say.
In the meantime you were provided with multiple alternatives, like using .let or using helper methods where you can freely use different names.

[poohbar]

1. Completely disregarding my use case and calling it “not sane” seems a bit over the top to me so that’s what I mean by “radical”.
2. I agree I can suggest it as a new feature.
3. I thank all you for providing alternative solutions.

you can say that and we can all disagree to that

I think saying things like this is pretty confrontational. You are somehow implying that everyone except me agrees with you which I doubt.

But whatever. Not going to waste mine or anybody else’s time on this further.

[Vampire]

I think saying things like this is pretty confrontational. You are somehow implying that everyone except me agrees with you which I doubt.

I'm not at all implying anything similar at all.
I said "we can", not "we do".
You were the one saying we all don't see a use-case where it is helpful and attacked us for having a different opinion than you.

But yeah, let's stop here. 🙂

[Ruckus]

@poohbar I think your first point is where a lot of this is breaking down, and it seems to stem from not everyone being on the same page. You claim that we're disregarding your use case, and others (myself included) claim this is essentially an XY problem.

Ultimately, from my perspective, it doesn't appear that you have presented your use case. You stated you have a use case that involves X (getting a different name for the same thing). In response, several people said the issue actually appears to be Y (the naming was wrong to start with) and fixing that would make X moot. You then never clarified what the use case that involved X is (this is where I think a lot of the confusion is: you appear to be claiming X is the use case, whereas others that have commented appear to be claiming how X is used is the use case). Perhaps if you could clarify better either how X is used (the use case others are seeking) or how X is in and of itself a use case that could be helpful.

[poohbar]

I think this all started wrong immediately with this response:

[poohbar]

I am asking how can I do something and the answer is that I don’t need to. Why not just say that it is not possible?

[poohbar]

Any sort of generic value processing where values can be of arbitrary types can benefit from this renaming. I can’t share the exact code because of NDAs but hopefully my second example illustrated it better.

[Chris Lee]

that’s already been explained - the smart cast works the way it works, reusing the existing variable as a different type. Changing the name is not currently possible with smart cast. Workarounds are possible as noted above.

[Ruckus]

Because "it's not possible" is not actually accurate in this case. There may be a perfectly elegant and idiomatic way to do what you're trying, we just don't know what that is. If your question is "how can I write Java in Kotlin" then yes, the answer is you can't.

[poohbar]

Fair points. I think creating methods or using let are good solutions. 👍

[Vampire]

I am asking how can I do something and the answer is that I don’t need to. Why not just say that it is not possible?

That was implied.
I'm sorry if that was not obvious.

[Ruckus]

You could achieve the same thing using

if (obj is String) {
    val myString: String = obj
}

But is isn't clear what your end goal is here. Do you just want another variable? Use val or let. Do you want Java syntax? Not possible (at least not currently). Do you just want elegant usage? No need to do anything, as smart cast covers that very elegantly. And that can go on and on depending on so many things.

[Ruckus]

Any sort of generic value processing where values can be of arbitrary types can benefit from this renaming.

This is where an actual use case could be helpful. In my experience, I haven't seen such a situation where starting with a better name wasn't a far better option. Of course, neither I nor anyone else here has seen every use case, so a real life example could be very illuminating, as we are clearly having difficulty imagining a case where your claim is true.

In your second example, to me it still feels like this issue is that obj was the wrong name to start with, as it is again a description of the type, not a semantic description of what the value represents.

[Ruckus]

Shame about the NDA. Maybe someday we'll get to the bottom of it all 🙂