https://kotlinlang.org logo
Title
d

Dias

04/08/2019, 4:00 PM
don't people find it confusing that
Any?.toString()
returns "null" rather than actual null?
🤣 2
:yes: 4
🇳🇴 8
r

Ruckus

04/08/2019, 4:10 PM
Of course not.
fun Any?.toString(): String
clearly returns
String
, not
String?
.
d

Dias

04/08/2019, 4:13 PM
it's only clear if you look at the definition of Any?.toString()
g

ghedeon

04/08/2019, 4:14 PM
It is confusing. It's one of those behaviours that you have to remember. Which usually means that you learn it by surprise. I had to look it up in the source code, first time I saw it.
1
4
k

karelpeeters

04/08/2019, 4:15 PM
That's true, but you only need to look it up once 😒imple_smile:
g

ghedeon

04/08/2019, 4:16 PM
Personally, I was expecting
""
, but I guess it's made like this in order to mark it as a special case, idk.
k

karelpeeters

04/08/2019, 4:18 PM
Then tostring for data classes would suck,
Point(x=5, y=)
r

Ruckus

04/08/2019, 4:25 PM
I disagree that it's "one of those behaviors you have to remember". If we're talking about
Any?.toString()
, we're talking about the definition. If we're talking about usage, it's fairly clear if I say
value.toString()
vs
value?.toString()
. If you understand nullability and safe execution in Kotlin, it seems perfectly clear.
👍 2
g

ghedeon

04/08/2019, 5:36 PM
Nullability is unrelated in my answer, mostly focused on the returned value. Seeing "null" string as item somewhere in the final collection or even as a button label on the screen was surprising because it's not a specified constant in java. Could be as well any kind of "special" string, deliberately chosen by JB. I'm not saying it's wrong, I'm saying that a lot of people will fail to guess what
null.toString()
is going to return from the first look.
o

orangy

04/08/2019, 5:41 PM
Guess the value of
String.valueOf(null)
expression in Java 😉
g

ghedeon

04/08/2019, 5:45 PM
I stand corrected then. But I've seen a few times people redefining this behaviour to
""
mostly in UI layer, because it makes more sense there. Anyhow, thankfully, custom extensions are easy to write.
c

cbruegg

04/08/2019, 6:14 PM
But I don't like that functions may have nullable receivers. As extension methods are supposed to mimic instance methods, it's surprising this works.
b

Burkhard

04/08/2019, 6:42 PM
I guess allowing
null
as the receiver of extension functions is a different discussion (and something that will probably never change). Anyhow I like it. Functions like
isNullOrEmpty
are great
r

Ruckus

04/08/2019, 6:46 PM
As extension methods are supposed to mimic instance methods...
That seems a rather unfounded claim. Can you justify it?
c

cbruegg

04/08/2019, 6:47 PM
Quite simply that at the callsite, they are indistinguishable from them.
r

Ruckus

04/08/2019, 6:48 PM
There's a significant gap between sharing a common syntax and "supposed to mimic"
c

cbruegg

04/08/2019, 6:48 PM
Fair point
Doesn't make my first time seeing this working less surprising though
r

Ruckus

04/08/2019, 6:52 PM
I can see where you're coming from, but the distinction between member and extension (and their associated strengths and limitations) isn't just important, it's quite useful. @elizarov has a great overview of this in his "Extension-oriented design" article: https://medium.com/@elizarov/extension-oriented-design-13f4f27deaee
b

Burkhard

04/08/2019, 6:54 PM
Also I don’t think there is a good way of avoiding that. Changing the calling syntax for extension functions would take away a lot of it’s power and probably end up like c++ with
.
vs
->
.
r

Ruckus

04/08/2019, 6:58 PM
@cbruegg There were quite a few things with Kotlin I found surprising when I first saw them working, but I never found that surprise detrimental. To the contrary, many of those surprises are precisely what make Kotlin such a pleasure to work with. They're "good surprises" if you will 🙂