https://kotlinlang.org logo
#getting-started
Title
# getting-started
p

poohbar

08/15/2022, 7:36 PM
Does Kotlin have an equivalent of the new Java feature:
Copy code
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?
v

Vampire

08/15/2022, 7:40 PM
The point is, you don't need to give it a new name, you can just use the same smart-casted name.
2
p

poohbar

08/15/2022, 7:42 PM
giving it a new name improves readability actually.. see this case:
Copy code
Object obj = "hello";
if (obj instanceof String string) {
    // work with 'string'
} else if (obj instanceof Integer integer) {
    // work with 'integer'
} else {
    // throw
}
j

Joffrey

08/15/2022, 7:45 PM
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?
👍 4
r

Robert Williams

08/15/2022, 7:47 PM
If you're doing enough that readability is an issue surely that's a sign that you should extract it?
Copy code
when (obj) {
is String -> handleString(obj)
}
...
private fun handleString(newName: String) {
// work with 'newName`
v

Vampire

08/15/2022, 7:51 PM
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.
p

poohbar

08/15/2022, 7:54 PM
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.
v

Vampire

08/15/2022, 7:59 PM
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. 🙂
👍 5
r

Ruckus

08/15/2022, 7:59 PM
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).
s

sreich

08/15/2022, 8:03 PM
i agree. more context needed. also if you reallyy wanted to go down that rabbit hole you can just do
.let { stupidName -> }
p

PoisonedYouth

08/15/2022, 8:04 PM
I can only support the arguments of the others here, variable name should describe the purpose, not type.
p

poohbar

08/16/2022, 4:25 PM
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.
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.
v

Vampire

08/16/2022, 4:32 PM
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.
p

poohbar

08/16/2022, 4:39 PM
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.
v

Vampire

08/16/2022, 4:43 PM
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. 🙂
r

Ruckus

08/16/2022, 4:50 PM
@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.
p

poohbar

08/16/2022, 4:51 PM
I think this all started wrong immediately with this response:
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?
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.
c

Chris Lee

08/16/2022, 4:53 PM
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.
r

Ruckus

08/16/2022, 4:53 PM
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.
p

poohbar

08/16/2022, 4:54 PM
Fair points. I think creating methods or using
let
are good solutions. 👍
👍 1
👌 1
v

Vampire

08/16/2022, 4:55 PM
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.
r

Ruckus

08/16/2022, 4:55 PM
You could achieve the same thing using
Copy code
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.
💯 1
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.
1
Shame about the NDA. Maybe someday we'll get to the bottom of it all 🙂
3 Views