Saturday, October 12, 2002

From the beating-my-head-against-a-brick-wall department: I snagged GotDotNet's Message Board sample and put it up on my machine at work to start a new intranet for the engineering group I'm in. In keeping with the idea that an intranet must be a communications tool that all employees check every day, I made a "Daily DotNet" forum and posted a code puzzle every day, to get some discussion going. The questions were mostly snagged from books. I got this one from Prosise's book: Spot the bug in the following code: int a = 1; Monitor.Enter(a); try { a *= 3; } finally { Monitor.Exit(a); } I was hoping to have some conversation about value types and boxing, but I had to just explain the answer, because there was no conversation. (a is boxed twice into 2 different objects, so there's a runtime error when Monitor.Exit tries to unlock an object that isn't locked). In five days of posts like the one above and in spite of repeated e-mails, I got exactly two one-line responses to the same question. From a group of thirty engineers. What's up with that? 3:24:56 PM

My first impulse was to take exception to this from Petzold's .NET book: Don't do this, however: Size.Width *= 2; That's setting a property of a property. For reasons beyond the comprehension of people who don't write compilers, it's not allowed. In a later example, he gives the right way to do this kind of thing, but he doesn't explain why the statement doesn't work. Should he have explained it? .NET has merged all Microsoft development cultures (Visual C++, Visual Basic, ASP) into one, so the new culture must satisfy the needs of those diverse groups. I've enjoyed developing in all three environments, but have often been frustrated by the lightweight nature of many VB conference sessions, books, and magazines, relative to the C++ equivalents (DevelopMentor providing some notable exceptions). Obviously the reason is that VB has a wider appeal than C++. It takes less skill to use VB but that doesn't mean it can only be used for development projects where less skill is needed. Just ask Joel. So back to Petzold's comment above. Should a comprehensive book like this just skip over this issue, because developers don't need to know it or won't be able to understand it? Shouldn't all .NET developers understand the differences between reference types and value types? I think so. I hope so. 9:22:14 AM

© Copyright 2002 John Sands.