If you look at the code I write, seeing a line similar to the following would be fairly common:
RaiseEvent LoadComplete(Me, New EventArgs)
Yesterday, I wouldn’t have given this a second thought, but today, the story is a bit different. A friend of mine pointed me to an interesting comment by David Kean (from Microsoft) on the MSDN Wiki indicating that the line above is actually wrong!
So, based on his comment, I should be using EventArgs.Empty instead of creating a new instance, something like this:
RaiseEvent LoadComplete(Me, EventArgs.Empty)
So using EventArgs.Empty
must be better somehow, so I decided to take a look and see if I could figure out just what the difference would be. The MSDN states that “The value of Empty is a read-only instance of EventArgs equivalent to the result of calling the EventArgs constructor” – so what’s the difference? Time for a trip into the Reflector.
The Reflector shows two constructors:
Public Sub New()
End Sub
Shared Sub New()
EventArgs.Empty = New EventArgs
End Sub
So, EventArgs.Empty
just calls New EventArgs
and returns that. Right.
Anybody see something there that I’m missing? Seems to me that the somewhat more verbose, but more clear (as to what is actually happening) syntax would be better, and no less efficient. If anybody has an opinion about why you would do one instead of the other, I’d like to hear it.
I installed Vista last night twice; the first was an upgrade from XP Pro on my laptop, the other a fresh install on my desktop. The experience was quite interesting for both; here are a few thoughts about the process:
Laptop My laptop has a fairly modest configuration, 1.73GHz Pentium M, 512MB, 80GB hard-drive, and Mobil Intel 915 64MB for the graphics. It’s been running Windows XP Pro, last night I went through the upgrade process to Vista Business.
It has been 20 years since I first used machine learning to solve a complex business problem. The underlying problem was simple: the company was selling a new service and wanted to know who was most likely to buy it. We had millions of records, and each record had hundreds of fields. A vast amount of data, but no idea how to extract insight from it. Countless hours from various data analysts had been invested into finding a pattern, but none was forthcoming.
In early December, about a month ago, I had the to perform one of the hardest tasks I’ve ever faced as a leader, letting my team know that a colleague had passed away. She was a friend to us all, and the glue that held the team together; telling them that she was gone was, without question, the hardest thing I’ve had to do in a work setting.
What made this so hard was not just what I was telling them, but my own feelings for her as a friend, and the opportunity I had missed.
Yesterday the news hit of a new vulnerability that threatens the security of all code; dubbed Trojan Source by the researchers from the University of Cambridge. From an initial analysis, it does seem to impact just about everything, and the status of fixes is very hit or miss at this point. But the real question is, does this even matter? Is this issue worth spending your time on? Let’s look closer.
I recently became curious just how much time I had spent working on content for this site, which led me to an idea: it would be great to have a page that listed some useful data about the content, and how much effort was put into it. I had some hope that I could pull some of this directly out of Hugo, though unfortunately it didn’t expose the information I wanted (and certainly not in an efficient way).