https://kotlinlang.org logo
Join Slack
Powered by
What's the difference between using a function vs ...
# announcements
t
What's the difference between using a function vs a property for exposing a internal var? Or is there any 
fun time() = internalTime
vs 
val time = internalTime
?
b
val time = internalTime
is immutable and would return the same value on each query whereas fun time() would (assuming it's not a constant).
Copy code
val time: Long
   get() = internalTime
Would be equivalent fun time()
t
I'm not sure I follow. internalTime is mutable and changes frequently. so a the property will only read it once?
I just don't want it modifiable outside of the class itself. I've never seen that syntax before. If internalTime is a private var does it still work?
b
yes it's assigning it during init
Where as
val time = internalTime
is immutable and update on each query whereas fun time() would (assuming it's not a constant).
Copy code
val time: Long
   get() = internalTime
Is returning internalTime each time 
time
is called
t
I see. what's the difference between that and 
fun time() = internalTime
? Or is it syntactic sugar for the same thing?
b
immutable to outside modification but still "updates" due to the get()
val equates to read-only realistically
Comes down to each purpose. I'd go with the class property for that usecase though
t
that syntax looks strange to me. is 
get()
some compiler magic? It doesn't look like a type, which is what you would expect there.
b
It's a property of your class/object
t
what else can go there besides 
get()
?
b
You can also do get {}. get() = can be used for brevity
Copy code
val time: Long
   get {
       return internalTime
   }
t
I just figured out I can do this :
Copy code
public var time:Long=0
    private set
I don't even need 
internalTime
any more. neato! Thanks man! learned something new about kotlin today
b
Hah of course :)
t
is this a kotlin thing, or was this kinda thing added to java at some point as well?
b
It's a Kotlin thing. In Java it is equivalent to the separate getter and setter methods for your field.
Copy code
private void setTime(long time) {}
public long getTime()
Also what it is at the byte code level when compiled
n
val time isn't necessarily immutable; it just means it can't be reassigned
if the type in question is not immutable, then the field isn't immutable, even if it is 
val
b
Right. Read-only
t
@Nir you mean external or internally? Obviously externally it can't be modified.. which is what I'm looking for.
n
there's no guarantee it cannot be modified externally either
t
hmm.. how so?
n
it's incredibly common amongst kotlin devs to overestimate the immutability guarantees that kotlin gives you
b
val can only be "assigned" once
n
Copy code
data class foo(val bar: List<Int>)
val x = mutableListOf(1)
val f = foo(x)
x.add(2)
t
you mean like if I pass it to something, the fact that it's 
set
is private get "erased" etc?
n
here we have a field that's 
val
and it's List, not MutableList
and yet, I can still mutate it from outside
if the type itself has a mutating interface, like 
MutableList
, or a dataclass with at least one 
var
field then it's even easier
b
In your example you aren't mutating "x"; your changing the contents of X
It's still the same list
t
hmm.. that just seems like a "cast" type problem. It can be casted to a list, but it isn't a list.
I'd read that code as telling bar "you can't change this", not "this can't be changed"
but in my time example where it's a long w/ a private set() how could someone external change it? does the compiler "forget" it's private under some condition/ As a function var that's expecting mutable?
n
uh what
"changing the contents" of x, is mutating it
b
Your not reassigning x
Is what I was saying
n
sure, you're not reassigning it, but you are mutating it
and consequently you're mutating the object that it's a part of
b
Yep
n
@TwoClocks it's not a "cast" problem
but yeah List doesn't imply immutability
Integers and Strings are really immutable.
They don't contain anything else inside.
List is Kotlin isn't truly immutable for like, two separate reasons 🙂
so 
val Int
is really immutable
t
So back to my question. in my example :
Copy code
public var time:Long=0
    private set
can 
time
be modified externally to the class/object that declares it? (I'm not saying anything about the mutability of 
time
here)
n
I think you're safe
t
I get your point though. people tend to conflate read-only w/ mutability.
n
yeah that's one big part of it (in kotlin)
the other part is that there's no transitivity for immutability
even a true ImmutableList in Kotlin isn't actually immutable
because it can be an ImmutableList<MutableList<Int>> for example
t
hard on the JVM to ensure anyway. scala had/has strange corner cases as well around immutability.
n
Yeah I've heard that often
6 Views
Open in Slack
PreviousNext
Powered by