don't people find it confusing that `Any?.toString...
# announcements
d
don't people find it confusing that
Any?.toString()
returns "null" rather than actual null?
🤣 2
🚫 8
👌 4
r
Of course not.
fun Any?.toString(): String
clearly returns
String
, not
String?
.
d
it's only clear if you look at the definition of Any?.toString()
g
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
That's true, but you only need to look it up once simple smile
g
Personally, I was expecting
""
, but I guess it's made like this in order to mark it as a special case, idk.
k
Then tostring for data classes would suck,
Point(x=5, y=)
r
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
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
Guess the value of
String.valueOf(null)
expression in Java 😉
g
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
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
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
As extension methods are supposed to mimic instance methods...
That seems a rather unfounded claim. Can you justify it?
c
Quite simply that at the callsite, they are indistinguishable from them.
r
There's a significant gap between sharing a common syntax and "supposed to mimic"
c
Fair point
Doesn't make my first time seeing this working less surprising though
r
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
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
@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 🙂