my understanding was that you would pick a propert...

# advent-of-code

[Nir]

my understanding was that you would pick a property for something that is essentially cheap/cached/"read off" and a function for something that actually requires computation.
So size as a property makes sense; any collection in Kotlin should cheaply know its size. But if it cheaply knows its size, it must cheaply know whether its empty? If size has to be cheaply available, then even having isEmpty as an extension property with size == 0 seems fine...

[ephemient]

good question. if it were a method on the super Iterable interface, that would make sense as they're not necessarily sized, but since Collection is always sized… I dunno

[Nir]

yeah, my thinking exactly

[Jakub Gwóźdź]

I’m not sure if it.empty is more readable than it.isEmpty() , as “empty” is also a verb and when skimming code, might suggest clearing the collection.

[Nir]

I'm confused, why does empty vs isEmpty have to do with property vs function?

[Jakub Gwóźdź]

@Nir scratch that, I retract my statement, you’re actually right… Imagine JAVA class

public class Foo {

  int size;

  public boolean isEmpty() { return size == 0;}
}

If I want to use it in Kotlin and I write Foo().isEmpty() , kotlin complains with warning that I should use Foo().isEmpty 😮

[Nir]

Yeah pretty much, standard library should have followed their own warnings, idk :-)