<https://youtu.be/FsAt_giaCSw>
# feed
o

https://youtu.be/FsAt_giaCSwā–¾

šŸ‘ 1
šŸ‘šŸ¼ 1
r
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?
o
well I could later implement it and use a linked list for storage instead of an array
but thatā€™s way later
b
Why did you opt to implement size and isEmpty as properties rather than functions?
o
that was a mistake
I correct it in the Queues episode
c
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.
šŸ’Æ 5
o
thats a good observation, in Queues I do end up calling the implementation ā€œArraylistQueueā€
b
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?
c
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.
šŸ‘ 1
o
I didnt know it would have such implications, so interesting
b
@oday one minor thingy: field
storage
can be
val
rather than
var
o
also true
c
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
(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)
(one exception is when using
lazy
, then it's ok to have a property that does a complicated calculation, because it's only once)