An interesting point comes up in that post by John, which is the double-Dispose problem. I think that's already here today, don't you? We should all be defensively coding our Dispose method so we don't do something twice that we shouldn't, as well as we should be ensuring that we haven't already been Disposed when someone asks us to do some more work. I doubt Chris' research work into DF will invalidate that needed code. [The .NET Guy]

You beat me to it! Believe it or not, I was thinking about this very same thing on my walk home. I was going to say how IDisposable really wouldn't help Chris with DF because it doesn't count references! IDisposable is lacking an IUnknown::AddRef equivalent. IDisposable is based simple ownership rules: I created this object, I know when best to destroy it. With weak ownership, you need reference counting to help with DF.

Personally, as I indicated in my "Is COM Interop Fundamentally Flawed?" response the other day, I'm fine with today's behavior. I've been working in a GCd environment long enough that I'm aware of all the pitfalls with GCd resources and the underlying system resources they may contain. Now that this topic is so well covered, new developers may get bit by it, but they'll be able to find out why and how to prevent it very easily. I really don't mind making the one call to Marshal::ReleaseComObject or IDisposable::Dispose, because if reference counting is implemented, I'm undoubtedly going to have to think/type even more and I lose all the benefits of a GCd environment. Remember, even though your resources aren't cleaned up right away... at least they're cleaned up eventually. ;)

As far as double-Dispose defensive coding, you're absolutely right. You should be protecting against multiple calls today. Basically, assuming I'm holding a disposable resource like a System.Drawing.Bitmap in my component, my Dispose implementation should look something like:

<codeSnippet language="C#">
  public void Dispose()
  {
    // If bitmap hasn't already been disposed of, dispose of it now
    if(this.bitmap != null)
    {
      this.bitmap.Dispose();
      this.bitmap = null;
    }
  }

</codeSnippet>

Every Microsoft component that I've disected, follows a guarding pattern similar to, if not exactly like, this.

Chris Sells just announced release 0.2 of the Genghis component library for .NET applications. Now if only Chris would stop dragging his feet on finding a source control solution for the project, more people could get involved... even if only to do some code review/tweaking. Just kiddin' Chris, you know we love ya! ;) Kudos to all the contributors, hopefully I'll have some time to play around with the new stuff later tonight.

Apple is on the offensive, their Switch campaign is in full effect. I'm no Mac guy, but I must admit OSX is a hell of a system from what I've read (whitepaper wise). I also like the features that are coming in the Jaguar release, although I question how it is Microsoft gets in trouble for integrating features like IM, but Apple most likely won't hear a single complaint. IMHO, if they can get enough application developers out there to bring quality products (designed specifically for OSX, no Carbon crap) to the table, they stand a good chance at making a dent in the PC market. As it stands they have Microsoft's Office v.X and Adobe's suite of products, which usually suits enough peoples' needs. Of course, a CLI implementation wouldn't hurt either. ;)

This thing's pretty cool. It's a Flash MX enhancement on the standard listbox control. I made a suggestion for improving it's usability though:

"This is cool. I do have one usability suggestion though: The fish eye effect only responds to the mouse. If I focus the list and am using the keyboard to jump to an item in the list, the selection jumps, but the fish eye effect does not follow. I believe that it should as I might want to use alpha-searching to scan the list and I need to see if I've hit the selection I was looking for."

To be honest, I'm not a big fan of Flash. I've created plenty of functional sites using standard DHTML and more recently SVG. I prefer sticking with those technologies because they are based off of XML and the DOM which means my knowledge of XML as a technology is transferrable between the two higher level technologies at an abstract level. Never felt the need to learn a proprietary object model and development environment. Granted they've opened up the file specification now, but I don't think it's going to make much of a difference... SVG has come a long way and is gaining industry support everyday.

Mahesh Prakriya just posted the source for the Allocation Profiler to gotdotnet.com's user uploads. This is a great tool if you want to make sure you're .NET app is performing well within the GCd enviroment.

Found this nice article (via Brian Jepson's weblog over at O'ReillyNet) about getting started with C# on Linux using Mono.

Dr. GUI .NET on strings in .NET

Another good article from Dr. GUI. First he starts off by covering the BCL class System.String. Next he goes into how the C# and VB.NET languages represent the type natively. Then, he the goes into the important comparison of System.Text.StringBuilder vs. System.String. Next, a quick overrivew of System.Text.Encoding. Finally, he finishes off by mentioning the existence of System.Text.RegularExpressions.

Except the missing piece here is that Chris Sells is doing research into determinstic finalization on the platform, and I'd bet good money that it'll be tied somehow to IDisposable (i.e., objects that say they want disposable semantics will automatically get reference counts). At least, if I were doing it, that's the first thing I'd consider. [The .NET Guy]

Absolutely. This was also one of the things I suggested to John Lam when he made an RFC to the DOTNET list for suggestions on possible aspects he could write as examples for his CLAW technology. Here's a recap of our exchange:

John wrote:

Do folks have other interesting ideas for aspects as diagnostic probes?

I responded:

Uhh... here's a cool one that would probably win you unimaginable amounts of
praise from the deterministic finalization crowd. How about an aspect that
is executed after a woven method that ensures that all local variables which
support IDisposable and are whose references are not already null are
reported and/or automagically Dispose()d of?

The reason I say "and are whose references are not already null" is because
there's unfortunately no other abstract indicator as to whether or not an
IDisposable object has truly been disposed of. Personally I think
IDisposable should support an abstract read-only Disposed property that
returns true/false based on whether or not the object has been in fact been
properly disposed of.

and John finished off the thread with:

Yes! I spent some time talking about this, and this was one of the "far
out" scenarios that I presented at the AOSD conference.

There are some limitations that need to be enforced, of course:

1) That the local var was never passed as a parameter to another method.
2) That the local var was never assigned to a field.

Technically you could walk the call-graph of 1) to ensure that it is
never assigned to a field, but that could be a nasty computational
rat-hole.

Some kind of weave-time warning could be issued if either of those two
constraints are violated.

The entire thread of conversation can be viewed via the list archives.