You've reached the internet home of Chris Sells, who has a long history as a contributing member of the Windows developer community. He enjoys long walks on the beach and various computer technologies.
Friday, Jan 24, 2003, 7:54 AM in .NET
ASP.NET: Tips and Tricks
Here. From Ben Kohn: See demonstrations of a variety of useful techniques and approaches that can be leveraged to help build powerful ASP.NET Web applications and Web Services. Learn about: debugging, tracing, event logging, performance counters, error handling, Web form session state, sending email from, file upload and others.
Friday, Jan 24, 2003, 12:00 AM in The Spout
OOD (The D Stands for "Dead In The Water")
Reading a very interesting book which I'll discuss in a future post, I came to a startling conclusion. As much as I love OO thinking and programming, OO databases are never going to fly. I realize that this may not be so startling considering how long OOD products have existed and how unsuccessful they've been so far, but the conclusion I came to was *why* they'll never fly. The reason is simple: the data itself is more valuable than the programs that use it.
For an OO guy, taught that behavior was everything and data was an implementation technique, that's a startling conclusion. However, the beauty of a database is that it's devoid of behavior, or, if there is behavior, it's layered in on top of the data. Programming languages come and go along with the ideas that underlie them and the applications that are built with them. Relational data, on the other hand, is a model that's simple enough, but complete enough, to move forward from application to application, accumulating value as you go in the data itself. And, since the relational model is so entrenched, no technology for the last 10 years or the next 1000 would be complete without support for it. Even Microsoft, IBM, GM and AT&T will prove to be less enduring than relational data, the tools to program against it and the tools to slice and dice it w/o programming anything (the latter are amazing strong already and continue to grow).
Data in OO databases, on the other hand, are bound to behavior and worthless for anything but the limited set of applications for whom the behavior was paramount and the data an implementation detail. When things change, as they always do, how are you going to get the data out so you can do things different? You're going to dump it to the simplest, most complete, most firmly entrenched data format that the world has every known -- relational data.
OO persistence formats are, by their natural, tied to a specific object model and therefore hopelessly proprietary. And with the emergence of XML, OO persistence formats are going the way of the dodo, even for applications running on machines without a database server. Why would I persist data to a closed format when I can choose relational data for the big stuff and XML for the small stuff? Both provide endless tools for slicing and dicing and bringing forward when the application dies. With OO persistence, when the app goes, so goes the data. The problem with OOD is that things are *too* seamlessly integrated. Ironic, no?
Thursday, Jan 23, 2003, 2:02 PM
Sealed Sucks
Here. Classes should *never* be marked as "sealed" because it ruins the entire model of type compatibility in exchange for dubious protections. .NET has already taken away my determininistic finalization. Must it also take away my ability to derive?
Thursday, Jan 23, 2003, 12:00 AM in The Spout
Sealed Sucks
I've come to the conclusion that the use of the "sealed" keyword in C# (and the concept in .NET) should almost never be used, at least on a class. Semantically, sealed applied to a class means that a class cannot be used as a base class. For example, the ImageList class from the System.Windows.Forms namespace is sealed:
public
sealed class System.Windows.Forms.ImageList : ... { ... }What sealed means is that the designers of the ImageList class didn't take the time to test what would happen in all the scenarios where an ImageList is specified but a subclass is provided, e.g. MyImageListEx2. So, since they didn't test these scenarios, they're protecting developers from deriving from the ImageList base class when bad things might happen. They're also protecting developers if the base class changes radically in the future and derived classes no longer work.
Stop it!
I don't want to be protected in this way! Instead, I want to try to derive from ImageList and see if it works in the scenarios in which I'm interested. And if future versions of the ImageList base class break my derived class, I want to update my derived class in ways that work across versions of the base class or have two versions or whatever else I need to do to make it work. By making a class sealed, I just don't have any choice in the matter, which severely limits me in what I can do.
As an example, I think that the current ImageList implementation sucks in the following ways:
- Every time you need to edit an image, you need to remove the old image and add it back again
- Images are too small to see what they are
- Can't tag images with names
So, I'd like to build my own ImageList implementation that has the exact same programmatic interface, but that pulls images from manifest resources, fixing most of the issues above. All of the controls that take images get them from an ImageList type, so I need to provide my extra functionality in a type that's compatible with ImageList. However, the only way to do that in .NET is via inheritance and the damn sealed attribute disables my ability to do that! Instead, I have to build a custom component that's also an extender provider if I want to provide the same design-time usage as an ImageList and I have to tell developers using my image list component not to use any of the ImageList-related properties because it will conflict with mine. I literally can't package my functionality in a way that's developer-friendly in the same way as the ImageList and it's all because it's *sealed*!
Of course, the ImageList class isn't the only one. I had a solution to the problem of asynchronous method calls to web services from WinForms apps the other day (the problem is that an extra hop is always required to get back to the UI thread), but my solution can't work because the base delegate type required to make an asynch call is sealed. And the list goes on and on of things that I can't do because somebody is "protected" me from potential bad things.
Please, please, please, please, please don't mark your classes sealed. If you do, folks that want to provide extended functionality, and test to make sure that it works the way it's supposed to, don't even have the option. Type compatibility is a huge deal when you're dealing with class-based abstractions instead of interface-based abstractions and using the sealed keyword throws all of that away. The C++ community survived very nicely without sealed for a decade and it's made half of the classes on my site possible.
You took away my deterministic finalization. Must you also take away my ability to derive?
Wednesday, Jan 22, 2003, 11:45 PM in .NET
Free VS.NET Trial DVD
Here. If you haven't done .NET yet because your company hasn't upgraded to VS.NET or you don't want to spend the money if you're not going to like it, you can get a 60-day eval copy on this link in exchange for giving up some personal details.
Wednesday, Jan 22, 2003, 1:16 PM in .NET
CodeSmith Integrated into VS.NET
Here. Eric Smith has integrated his CodeSmith code-generation tool directly into VS.NET. Very nice.
Wednesday, Jan 22, 2003, 1:07 PM in Tools
NUnitASP
Here. From Colin: NUnitAsp is a tool for automatically testing ASP.NET web pages. It's an extension to NUnit, a tool for test-driven development in .NET.
Tuesday, Jan 21, 2003, 7:03 PM in .NET
Another C# Refactoring Tool
Here. A VS.NET add-in that provides the following C# refactoring operations: -Encapsulate Field -Extract Method -Inline Temp -Introduce Explaining Variable -Move Method new -Rename Field -Rename Method -Rename Property -Rename Local Variable -Rename Parameter -Replace Magic Number with Symbolic Constant -Replace Temp with Query It seems to be implemented in Java and then ported to .NET via J# and the web site has the coolest little visitor counter control.
Tuesday, Jan 21, 2003, 6:58 PM in .NET
Talking C#/CLR with Microsoft
Here. An interview of Peter Hallam, the dev. lead for the C# compiler. Most of the interview covers stuff you're likely to already know, e.g. the design goals for C# and the CLR, etc, but Mr. Hallam does spend some time talking about generics and his opinion on mono (he likes it).
Monday, Jan 20, 2003, 9:37 PM
Smart Displays Now Available
Here. Oh man, I *so* want one of these, but I can't decide whether to get the 15" one and use it as a monitor as well as a tablet, get the 8" for cuddling up to in bed or something in the middle! Also, does anyone know if these things support the same software as a TabletPC? They certainly should.
Monday, Jan 20, 2003, 8:51 PM in .NET
COM & WinForms...Happy together?
Here. From Shawn Wildermuth: Chris has a new article up on http://ONDotNet.com on Hosting your Windows Forms controls in COM Containers? Wouldn't you love to use the DataGrid inside your MFC project?
Monday, Jan 20, 2003, 7:19 PM
I/O, I/O, It's Off to Work I Go
Here. Eric Gunnerson discusses the basics of .NET stream-based I/O. Not very deep, but I'm still surprised at how few .NET programmers understand how streams work.
Monday, Jan 20, 2003, 7:17 PM in .NET
C# and Java: Comparing Programming Languages
Here. This is a pretty comprehensive, and pretty even-handed, comparison (Java gets kudos for doing some things better than C# and vice versa). If you're still curious about how the other half lives, check it out, but I'll bottom line it for you: C# and Java are pretty much the same language. The real differences are in the respective libraries, not the languages.
Saturday, Jan 18, 2003, 10:24 AM
Media2Go Preview
Here. The idea of Media2Go is a PDA/MP3-player-style device just for A/V, e.g. a video-enabled iPod. I have mixed feelings about it. I think I'd rather watch videos on my laptop and get an audio-enabled cell phone than carry yet another device.
Saturday, Jan 18, 2003, 10:17 AM
SPOT On
Here. While I think that the prototype watches are butt ugly, I really want to write apps for my watch. With a decent metal frame and a color screen, the Smart Personal Object Technology (SPOT) watches would rock. BTW, does anyone else thing that the Win32/.NET/SPOT windowing API needs to be updated for non-rectangular displays?