Just my opinion but I think this behavior should be strongly discouraged. It creates an unnecessary dependency of the broadcaster on the listener, which totally defeats one of the elegant features of using the listener in the first place: That the broadcaster doesn’t care how many or what particular listeners are attached.
Correct me if I’m wrong but I think juce Listeners work this way:
 Anyone can add themselves as a Listener at any time.
 A Listener must remove itself before the broadcasting object is destroyed.
 A previously added Listener may be removed at any time.
[3.1] A Listener may remove itself from within a Listener callback.
[3.2] It is safe to remove any installed listener from within a Listener callback.
 The Listener callback is made from the thread of the broadcaster.
For #2 this was the subject of a lively discussion regarding the implementation of a “ScopedListener” (here: http://rawmaterialsoftware.com/viewtopic.php?f=2&t=6401), designed to ease lifetime management for attached objects. Unfortunately this won’t work with some complex concurrency models but it was a nice idea.scope
My entire application is built on the Listener concept (except that Listeners can specify on which thread they want to be notified, a non trivial implementation). They are extremely robust and in my opinion it is the superior model for implementing the type of concurrent systems typically encountered in the development of audio applications or live performance tools. Listeners can be thought of as a very simplified form of MPI (Message Passing Interface) which works between threads instead of between processes:
Just my opinion but I think this behavior should be strongly discouraged. It creates an unnecessary dependency of the broadcaster on the listener, which totally defeats one of the elegant features of using the listener in the first place: That the broadcaster doesn’t care how many or what particular listeners are attached.[/quote]
I think you’ve missed his point there (and read some other meaning into his words), because he’s simply describing a broadcaster/listener relationship. I.e. in the first section he’s saying “for listeners…”, and then “for broadcasters…”.
I disagree, in his second code snippet “otherClass” is clearly the listener, and the call to addListener is implicitly “this->addListener(…)”. Because otherwise only the first example is needed. He then goes on to talk about the broadcaster needing to know about lifetime management of the listener, which lends further support to my interpretation. Of course if chkn wants to clear this up that would be best
But regardless, I still assert that having broadcasters manually add known listeners is a bad design.
the second example describes that I’m the broadcaster and otherclass is the listener, this->addListener(otherclass), and i thing regardless if i’m the listener or broadcaster, i think, who is adding the relationship, should also have the responsibility to care. You may say its a bad design, and you probably right, but it is wrong?
There are some places where in the JUCE codebase where a listener is added to a broadcaster, not by itself. Is it a bad-design and why? (Thats why i want to have some rules here, or new Listener Design which cares about lifetimes).