MEF lab [How to: Keep implementation details out of a MEF contract assembly by implementing an interface-based event handler]
**
This blog has moved to a new location and comments have been disabled.
All old posts, new posts, and comments can be found on The blog of dlaa.me.
See you there!
Comments
Anonymous
March 16, 2011
Presumably another way would be to eschew events and expose IObservables instead?Anonymous
March 16, 2011
Samuel Jack, Assuming the same problem doesn't come up, that seems reasonable as well! :) From my current perspective, people seems to be pretty divided on whether to embrace the Rx framework or not, so I'm not sure I'd make it part of an official API just yet. Something else that's kind of interesting to follow is the Visual Studio Async CTP (i.e., the "await" keyword): msdn.microsoft.com/.../async.aspx Of course, that's also not finalized, so I wouldn't use it in an official API, either. :)Anonymous
March 16, 2011
if (null != handler) { handler(this, new MyEventArgs("MyEventArgs")); } Nice use of Yoda expressions :-)Anonymous
March 17, 2011
Stimul8d, I assume you mean "null != handler" vs. "handler != null"? Yep, someone gives me a hard time about that every couple of months or so... :) For people who don't know why the former might be preferred, here's a pretty good discussion (there's also some coverage on StackOverflow): www.c2.com/.../wiki The good news is that C# doesn't have quite the same risk as C/C++ because of "warning CS0665: Assignment in conditional expression is always constant; did you mean to use == instead of = ?". However, there are two reasons I continue to use this pattern:
- I still code in C/C++ from time-to-time and like to use the same coding conventions everywhere.
- It's only a warning in C#, so someone may ignore it, suppress it, etc.. In case it matters, after a little while putting constants on the left, you won't find it hard to read anymore. At this point, I find it quite natural... :)