Signals

[IlyaGazman]

Hey, I also created an events library.
It's called Signals.

What do you think are the pros and cons of using each of our libraries.

[engor]

Hello, your code looks similar to this one, but its reflection based, right?
I can't tell you pros and cons w/o using in a project. :)

Note: there is a strange break in your loop which notify listeners: if listener==null break; (pseudocode as I remember it),
looks like it's for case when we remove listeners during iterating them,
maybe it works good but I have some doubt :)

[IlyaGazman]

Yeah, they are very similar.
I think that with your implementation, it is easier to create events for a single data type.

My implementation requires one extra step of declaring the event interface, it gives you two advantages.

• You are more flexible with the event signature, a number of arguments, and multiple functions.
• It's easier to navigate the code. You can see who calls the interface method and who implements it

About the strange break

synchronized(synObject) {
                    listener = if (i < listeners.size) {
                        listeners[i]
                    } else {
                        null
                    }
                }
                if (listener == null) {
                    break
                }

I allow to add and remove listeners during the dispatch phase. It means that listeners.size can change while iterating on the listeners. In java, you can break from a synchronized block, but not in Kotlin. So when i gets out of range, I mark the listener with null to break the loop.

[engor]

What if loop is iterating right on 3th item (of 10 for example) and I remove the first one - so that next item will be 5th not 4th ?

[IlyaGazman]

Good point!
Tnx, I missed that.

I will add unit tests to verify all those scenarios.
Right now, the solution that I am thinking about is to switch working with LinkedList. Instead of using random access, I will use the next node reference.

[engor]

I also saw such solution - put all listeners into new local list then iterate it, not class member property.
so that we can modify class property and it have no affect to iterating process, but if one listener should remove another one by some conditions - we cant achieve that. Not very simple things :)

[IlyaGazman]

Wow, I implemented it, and now the code looks much better—much better readability.
Tnx again for pointing this out.

[engor]

Cool :)