https://kotlinlang.org logo
Join Slack
Powered by
Stupid control flow question When(something){ ...
# announcements
c
Stupid control flow question When(something){ in group1 -> tada1 in group2 -> tada2 } but what if I wanna check when(string) and if the subsequent offered strings contain the value inside of my when?
Copy code
val incomingString = "A lot of things that are not interesting but this: ThePath"
when(incomingString){
        "The Path" -> something
        "No Path" -> something
            else -> somethingElse
}
Better example
a
What does 
subsequent offered strings
mean?
n
Either use if else, or use when without a target, and either way feed the boolean conditions, whatever they are
c
val incomingString = com.hell.syntrofos.ui.userDetail.ui.notes.noteFragment.NotesFragment when(incomingString){ “Fragment1” -> something “Fragment2" -> something }
this obviously doesn’t work
I wan’t to exclude the obvious answers because I’m using the class path example as an exercise
it could be anything]
a
It does work in my case.
is incomingString really a 
String
?
c
Copy code
val incomingString = "A lot of things that are not interesting but this: ThePath"
when(incomingString){
        "The Path" -> something
        "No Path" -> something
            else -> somethingElse
}
Yea
but I wanna search the incommingString for this partial String
a
Oh, you meant to call contains...
c
yea
I tried called contains but I would need to do incommingSgtring.contains(blabla) ->
which looks like defeating the purpose of using when
I couldn’t find anything similar here https://kotlinlang.org/docs/reference/control-flow.html
a
No, iirc you can search the given receiver in when against a long String (or a number in a range), but not the opposite.
c
yea 😕
for my case I can do just compare to class identifiers but I was curious if you could do it against contains
a
How bout 
"The Path" in incomingString
?
h
yes, and use when without the argument
c
Let me try it out
Yea but then you don’t really need this when syntax
😕
You can just if it out
a
single line statement in when still looks better 😛
c
but I guess this is a good as you can get with it and if you have a common else situation you can profit from the when sintax
👍 1
t
when{ incomingString.endsWith("The Path")-> something ... }
when(arg) can be used for simple (equals/is) matching. if you want to use complex expression, use when without argument value.
also you can use inner function to shorten repeated expression.
fun foobar(){
val str="..."
fun a(k:String) = str.endsWith(k)
when{
a("1")-> ...
a("2")-> ...
a("3")-> ...
}
}
➖ 2
➕ 2
c
interesting
t
when
can always be replaced with if/else syntax. Using it with a parameter is just additional sugar if you only need equality or type checks. It's usually also easier to read than a list of 
else if
blocks. I'd advise against doing something like this 
foobar
example. It makes the code a littlie bit shorter, but actually harder to read, because the additional function needs to be read. If I read 
"MyString" in incomingString
or 
incomingString.matches(something)
, I know what's happening and there is no added complexity of an additional local function that doesn't add any functionality.
➕ 2
h
well you can just give a meaningful name to the function
c
Copy code
fun foobar(k: String){
    fun matches(s:String) = str.contains(s)
    when{
        matches(k)-> ...
        matches(k)-> ...
        matches(k)-> ...
    }
}
maybe he ment something like this, at least that’s how Ì understood
t
you could, but what's teh point? If your check is that simple, the function doesn't help. And even with this example: I need to look at the function to really know what's happening (what matches the argument?). Your're just replacing one (well known) call with a different (custom) call.
h
well if you need to change the logic of matching you do it in only one place, it seems less error prone to me and more readable. you don't have to name it 
matches
, it could be anything significant
a
He meant making an anonymous function is just an overhead.
c
got it
h
if you meant performance overhead, then not really. you can easily see that when using 
inline
functions on functions without a lambda argument, the checker tells you that is is useless. if you meant writing overhead, then it is worth it, because if you have 100 calls and in the future you would want to change the matching logic, it is a pain to change all of them. that's why we do refactoring and abstractions, to make easily modifiable code
t
I meant writing overhead. And whether it's worth it strongly depends on the complexity of your check. If you just check for 
in
or do a simple function call, it can very easily be changed for many lines at once (especially it they are all in the same block). If your check is more complex, it is also a lot more likely to change and extracting it probably makes sense. Besides: if you have 100 branches in a single when block, please refactor your code!
h
well, the conclusion would be that it depends heavily on the case. thanks for the discussion, useful insights K
t
...as always...
c
Right? I was kinda happy to ask this question, wonderful discussion!
K 1
t
if same expression occurred repeatly, there is no reason to avoid making function for it. of course good naming is more better.
also in this question, parsing rule of incomingString was not provided. using endsWith is just my guess. if same parsing rule can be applied, you should apply before using when.
6 Views
Open in Slack
PreviousNext
Powered by