https://kotlinlang.org logo
Join Slack
Powered by
<https://medium.com/@elye.project/the-missing-trap...
# feed
e
r
When takeIf returns null, it shouldn’t be allow to get chained directly into any function without the ? check.
Why do you think this? What if you have a function you specifically want to call that takes a nullable receiver?
e
I think it could be done through Elvis expression. I think anything that could return a null or nonNull, should only follow by 
?.
t
he is complaining about the wrong problem
The real answer is that takeIf should return a Maybe, not a null
(sorry forgot the maybe equivalent in kotlin)
with null you are not sure if it's the condition that failed, or if the object is actually null
as @elye said, there might be a case when you actually want to do stuff with the null
r
Maybe
wouldn't solve the problem. The root issue here is that 
apply
can take a nullable receiver, and you need to watch out for it.
t
what if you want to treat the null?
it should be a maybe that takeIf returns
r
Then you do, thus 
.apply
can take a nullable receiver. If you don't want to, you specify 
?.apply
. In this case 
Maybe
has no benefit over a nullable type.
t
generic functions should all avoid returning 
null
, otherwise it cause problems with nullable tupes
r
No they shouldn't, that's the point of having nullability be part of the type system.
➕ 2
t
maybe has the benefit of knowing whether the value was null or it takeIf clause failed
You might want to do different things based on that
r
That doesn't make sense. By definition takeIf returns null if it fails. If you want to have more control, you use type safe operators like 
?.takeIf
t
It's 
takeIf
definitation that I'm contesting
r
Ah, I think I see what your trying to say. I still disagree, but I at least see where your coming from.
t
maybe I'm looking at this wrong, I'm still getting started with Kotlin
r
It's important to remember that Kotlin isn't a functional language, it just has some functional constructs.
I have to go catch a train, so I'll be off for a while.
t
i'm reading more stuff and 
?
seems to work like a monad maybe, I need more reading and proof. then for that example in the linked article, shouldn't the 
doThis()
method have the type 
object?
?
sorry not what I meant, I actually meant 
doThis()
being a method of some nullable class?
g
Actually this is not a problem of 
?.
operator at all, it’s wrong usage of 
takeIf
function in this article. Because looks like 
doThis
is just a function or method in context. You never should use takeIf like that. Take if make sense if you want to use someObject itself (pass it somewhere or call method) it’s not a replacement for general if condition
👍 2
@tmg Looks like doThis() in this example is just a method or function in context of this code, not a member function of someObject, so all those manipulation with takeIf don’t have any sense. Simple and correct if condition converted to hard to understand incorrect code that uses extension function takeIf in a wrong way
💯 1
g
I guess what's interesting to me, and I didn't know before, after reading this is that it's possible to use 
apply
on a variable that's 
null
, unless you try to access the variable in the passed lambda in a non-
null
fashion.. even though 
apply
is defined on 
T
instead of 
T?
g
T
means that type can be nullalbe or non-nullable. If you want to define generic that allows only non-nullable types you should define it as 
T : Any
g
good to know, thanks!
g
so apply that works only with non-nullable types will look like:
Copy code
public inline fun <T : Any> T.nonNullApply(block: T.() -> Unit): T {
    block()
    return this
}
t
Thanks for the info guys!
r
I agree it's a bad use of 
takeIf
and 
apply
. The author claims the new block is somehow an improvement, but if you ask me it's way less readable than
Copy code
if (someObject != null && status) doThis()
Using different syntax is only an improvement if it actually improves.
2 Views
Open in Slack
PreviousNext
Powered by