<https://youtu.be/FsAt_giaCSw>

# feed

[oday]

https://youtu.be/FsAt_giaCSw▾

[rtsketo]

Very nice video. Short, infomative and straight to the point.
What's the point of using an interface for a Stack instead of an open class?

[oday]

well I could later implement it and use a linked list for storage instead of an array

[oday]

but that’s way later

[Benoît Liessens]

Why did you opt to implement size and isEmpty as properties rather than functions?

[oday]

that was a mistake

[oday]

I correct it in the Queues episode

[CLOVIS]

I don't think it's a good idea to call it StackImpl. That's not a name that helps anyone understand what it does. You should probably call it ArrayListStack or similar, and add a `stackOf()`/`.toStack()` functions that use that as a default if you want to explicitly use it as a default.

[oday]

thats a good observation, in Queues I do end up calling the implementation “ArraylistQueue”

[Benoît Liessens]

Regarding the implementation of size and isEmpty as properties of `Stack`: both reflect state of the Stack rather than behaviour such as pop() and push(). I was expecting that to be the driving factor to choose between "property"-based vs "method"-based implementation. Does that make sense at all?

[CLOVIS]

It does make sense, but here both choices (property/function) are valid, depending on the semantics you want to communicate:

stack.size
Implies that the size is easy to calculate (low complexity)

stack.size()
Implies that the size is hard to calculate (high complexity, if you use it multiple times in a function you might want to create an intermediary variable)

There's also the question of Java/JS interop (it might make sense to make it a function, because it's one in Java).

The problem with the complexity thing above is that it doesn't work well for interfaces (you can't know in advance whether it will be expensive to calculate or not). If it were up to me, I'd make them properties, but I see why some people don't like that.

[oday]

I didnt know it would have such implications, so interesting

[Benoît Liessens]

@oday one minor thingy: field storage can be val rather than var

[oday]

also true

[CLOVIS]

I mean, these are not rules, more like “if you see this code, this is how people will think about it”, so you can take advantage of that to help people read your code

[CLOVIS]

(by the way, it's not something I came up with, it's completely on purpose by the Kotlin team, for example that's the reason you can't have a suspending getter—properties should not do complicated stuff)

[CLOVIS]

(one exception is when using lazy, then it's ok to have a property that does a complicated calculation, because it's only once)