| |
 |
Sunday, June 09, 2002 |
I, too, believe that the COM Interop is broken because it doesn't leverage IDisposable. I have to think this is one hand not knowing what the other hand is doing, given that IDisposable was really only put it because of the intense pressure by the .NET Beta community (mostly Chris Sells).
I wonder how much effort it would be to have someone else make a new COM interop tool that could grok a typelibrary, and generate the same goo, but with IDisposable tacked in for good measure. Has anybody approached this? [The .NET Guy]
Brad is in the same boat with Sam, but... I think I'm in there too. ;) The only difference that I see between their point of view and mine is that I don't consider it "broken", beause there is a way to deterministically scope the lifetime of the COM object reference (i.e. use Marshal::ReleaseComObject). In the end you will always need to do some extra work in your component to make sure that the reference is cleaned up, regardless of whether or not they implement IDisposable::Dispose. It's just a matter of what you need to type. C# is the only language that has special semantics for IDisposable (i.e. the using statement) which is definitely nice, but what about other languages? Take VB.NET for example, those developers will still have to type out the Try/Finally and at that point the only difference is what they type in the finally block: Marshal.ReleaseComObject(myComVariable) OR myComVariable.Dispose(). Now that's not to say that VB.NET and other language won't eventually gain a shorthand statement for the IDisposable pattern like C#'s "using", but it's not there today in any other CLR based language that I'm aware of.
So to sum up, the only point I'm trying to make is regardless of the semantics of releasing the underlying COM object reference, you will always need to do some extra thinking/typing in your program to make sure the reference gets released exactly when you want it to. [Drew's Blog]
9:02:14 PM 
|
|
That's why [.NET's COM Interop is] flawed. Microsoft should have all RCWs inherit from IDisposable where the Dispose implementation is provided System.__ComObject. That's my point. Instead of requring large COM companies to do all this for hundreds of components, they should have done this in the RCWs! That would have made COM Interop useful for large COM shops. As it is, it is not. Maybe in v.Next of .NET we can hope such an adjustment is made. Until then, its not very useful. [Sam Gentile's Radio Weblog]
I, too, believe that the COM Interop is broken because it doesn't leverage IDisposable. I have to think this is one hand not knowing what the other hand is doing, given that IDisposable was really only put it because of the intense pressure by the .NET Beta community (mostly Chris Sells).
I wonder how much effort it would be to have someone else make a new COM interop tool that could grok a typelibrary, and generate the same goo, but with IDisposable tacked in for good measure. Has anybody approached this? [The .NET Guy]
8:59:32 PM
|
|
Drew Marsh has supplied a through response to my premise that .NET COM Interop is fudamentally flawed. His summary is that it is not (flawed). He quite correctly traces the origins of P/Invoke and COM Interop (RCWs and CCWs) to Visual J++ and WFC. I did work with WFC and Visual J++ in 1997 too but apparently not enough to get to the RCW and CCW stuff.
He nails my conclusions with "The fundamental problem with COM interop in both runtimes is that you're mixing garbage collection with deterministic finalization. For what COM interop is out of the box, I think it is good enough. For more complex scenarios where you need to control the lifetime of the underlying COM resources, both runtimes provide a releasing mechanism. Yes, you have to take a little bit more control in these scenarios. Yes you have to have use a try/finally pattern with a ReleaseComObject call to clean up your resource. It's not the end of the world. Everyone knows this now, it should be common knowledge learned easily by reading a chapter in a .NET book on COM interop or by searching through newsgroups and mailing lists and now by reading community weblogs."
Well, you started off well there Drew before you reached into a generalization, but it just isn't quite that simple. For non wizard created complex real-world COM Components that do insider marshalling, connection points and that kind of stuff it's bloody hell. We have had COM experts from Microsoft (including Adam Nathan) as well as having a talent pool of over a hundred COM enigneers (most of whom soak in the stuff all day long since 1993) have huge problems. Its not simple. Why? You hit in your final observation:
Now as a final observation, I will say that we do have a new pattern in .NET that we did not have in Java/COM. That pattern is the IDisposable pattern. Early on when .NET was in it's beta2 days and IDispoable had just been defined I wondered why all RCWs didn't inherit from IDisposable where the Dispose implementation is provided by System.__ComObject and looked just like this: <codeSnippet language="C#">
public void IDisposable.Dispose(){ System.Runtime.InteropServices.Marshal.ReleaseComObject( this);}
</codeSnippet>
Agreed. That's why its flawed. Microsoft should have all RCWs inherit from IDisposable where the Dispose implementation is provided System.__ComObject. That's my point.
Instead of requring large COM companies to do all this for hundreds of components, they should have done this in the RCWs! That would have made COM Interop useful for large COM shops. As it is, it is not.
Maybe in v.Next of .NET we can hope such an adjustment is made
Until then, its not very useful.
4:06:09 PM
|
|
Of course, with Sue going to a wedding shower leaving us two boys to go out, I had to make sure Jonathan and I had the proper Geek day out. After all, it is my responsibility for my 4 year old to learn all things Geek-). The day started with catching up with all our comics at The Comic Store in Nashua. Then, of course, we had to make our trip to Barnes and Noble superstore where Jonathan got some Star Wars books and I picked up Bob Beauchemin's Essential ADO.NET definitive book on ADO.NET. As most of you know already, Bob is THE Data man on Windows and .NET. From there, it was on to Toys R Us for Star Wars figures. Then on the virtual second home of the Geek, Starbucks. The culmination was shopping for a new Titanium Mac Power Book at CompUSA, with a StarWars (see a pattern here for Jonathan) game for Jonathan and a Suse Linux 8.0 for me! Awesome bonding day. Now if I could just get him to do some .NET coding-))
3:39:38 PM
|
|
Sam Gentile: I have seen a lot of postings on REST ... vs. SOAP... someone please articulate in a sentence why I should care...
Analogy: ...within databases, you will likely find that something like SQL is great for queries, but you want to step back into the [stored] procedure world for updates.[Sam Ruby]
This is a pretty good analogy because SQL is a unbelievably limited query language just as REST is an unbelievably limited, er, whatever it is supposed to be.[Patrick Logan's Radio Weblog]
I guess I didn't quite get the analogy and still don't understand what REST is and why anyone should care. I still maintain that SOAP is building very functional and important systems today.
10:17:48 AM
|
|
© Copyright 2002 Sam Gentile.
|
|
|
|
|
