..NET suggests but does not enforce a conventional signature for events,
namely two parameters 'sender as object' and 'e as XxxEventArgs'. If you
deviate from this convention, things work fine, but FxCop complains (at least
1.32 does).
If I ignore the convention, what I have is a method whose signature is
designed by the object's programmer and whose implementation deliberately
left to the consumer to omit or implement as he sees fit. That sounds like a
nice programming element to have. For example, consider transaction
processing that outloads various things at various processing steps.
Outloading implemented as events gives you lots of operational flexibility
without having to re-deliver the transaction processing objects. Also, the
outloaded data would not be buried in an eventargs type of element (a kludge
imo).
So, what do you think? Where did this convention come from? Is it just the
way the chips fell after event-izing windows callbacks? Why is FxCop so
definite about it and .NET is not? Maybe .NET should offer vanilla events
(conventional signature) and rocky road events (custom signature), and FxCop
should respect same.
