Why must EventBroker subscribe methods/publish events be public?

[itamar]

Just noticed that I can't set up protected subscriber methods for
events... any special reason for this? I'd like to suggest that it
binds to all the types, public/protected/private/static. As for the
publisher events, I can understand the case that it should only be
public.

Another suggestion, and a solution for the above, is to change the
EventInspector class into a public class so that it can be extended.
From there I can generate a new custom IFactory and replace the
IEventInspector impl with the new extended class. Thoughts?

I didn't know if I should open an issue on this or not so I'm posting
this here first.

Thanks for the great library.

[Urs Enzler]

> Just noticed that I can't set up protected subscriber methods for
> events... any special reason for this?

This is a design decision. Because it is a call from the outside, I
prefer to make the handler method public. A public method makes this
clear, wheras a protected or private method would often rise
questions. However, this is a question of taste.
This simplifies unit testing, too. The unit test can call the handler
method directly. We test that the objects are wired correctly on the
event broker in our acceptance tests, not in unit tests.

> Another suggestion, and a solution for the above, is to change the
> EventInspector class into a public class so that it can be extended.
> From there I can generate a new custom IFactory and replace the
> IEventInspector impl with the new extended class. Thoughts?

Yes, EventInspector should be public. My fault :-(
As a workaround, You can override the StandardFactory and return your
own implementation of IEventInspector. For now, you'll have to copy
the complete code from EventInspector and adapt the resolution code
looking for the attributes.

> I didn't know if I should open an issue on this or not so I'm posting
> this here first.

Please, open an issue to make the EventInspector public with virtual
members.

But, I won't change the behaviour on the subscriber methods in the
default implementation (for the above reasons).

> Thanks for the great library.

Your welcome, and thanks for using it and helping to improve it.

Cheers
Urs