https://kotlinlang.org logo
#feed
Title
# feed
r

Ruckus

11/28/2017, 10:19 PM
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

elye

11/28/2017, 10:27 PM
I think it could be done through Elvis expression. I think anything that could return a null or nonNull, should only follow by
?.
t

tmg

11/28/2017, 10:31 PM
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

Ruckus

11/28/2017, 10:35 PM
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

tmg

11/28/2017, 10:36 PM
what if you want to treat the null?
it should be a maybe that takeIf returns
r

Ruckus

11/28/2017, 10:37 PM
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

tmg

11/28/2017, 10:37 PM
generic functions should all avoid returning
null
, otherwise it cause problems with nullable tupes
r

Ruckus

11/28/2017, 10:38 PM
No they shouldn't, that's the point of having nullability be part of the type system.
2
t

tmg

11/28/2017, 10:38 PM
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

Ruckus

11/28/2017, 10:40 PM
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

tmg

11/28/2017, 10:42 PM
It's
takeIf
definitation that I'm contesting
r

Ruckus

11/28/2017, 10:43 PM
Ah, I think I see what your trying to say. I still disagree, but I at least see where your coming from.
t

tmg

11/28/2017, 10:43 PM
maybe I'm looking at this wrong, I'm still getting started with Kotlin
r

Ruckus

11/28/2017, 10:44 PM
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

tmg

11/28/2017, 10:45 PM
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

gildor

11/29/2017, 3:44 AM
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

geatmo

11/29/2017, 9:15 AM
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

gildor

11/29/2017, 9:31 AM
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

geatmo

11/29/2017, 9:31 AM
good to know, thanks!
g

gildor

11/29/2017, 9:32 AM
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

tmg

11/29/2017, 9:33 AM
Thanks for the info guys!
r

Ruckus

11/29/2017, 4:21 PM
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