I had an interesting idea.  See, there's a good reason .NET does not allow multiple class inheritance, although multiple interface inheritance is allowed.  But there are some cases when it would be nice to be able to inherit the behavior of a class while still inheriting from another class.  Consider a simple example.

Say we have a class named Dog and a class named Cat.  As logic would tell us, there is no way something could be both a Dog and a Cat; hence, we cannot inherit both Dog and Cat.  An interface, however, has a different purpose than a class.  Instead of representing a type of object and including its implementation, an interface is intended to describe one or more capabilities of an object.  For instance, we might have an interface called IBarkable, which the Dog class would implement, describing its ability to bark.  Similarly, an IMeowable interface.  Now while there is nothing that is both a dog and a cat, there easily could be an object that has some of the capabilities of both.  For instance, a human can both imitate a dog's bark and a cat's meow.  So it makes sense that a class can implement more than one interface.

However, say we wrote the Dog and Cat classes already and now we're writing a Human class.  We've already written the code that performs the bark and the meow, how do we get that implementation into the Human class?  Now this is a very simple example and could probably be easily done a number of ways, but there are more complex situations similar to this where multiple inheritance would be helpful.  But it still does not justify allowing a class to inherit two base classes.

Here's where my idea comes in:  A new kind of type called a behavior.  Its purpose would be to define an implementation of a capability that is inheritable in a class.  Here's how a behavior would differ from a class:

• A behavior would be implicitly abstract in that it could not be directly instantiated.
• Polymorphism would not apply to behaviors.  Meaning that an implementing class could not be referenced as an object of a behavior.  As a result, variable types, parameter types, etc. could not be behaviors.  This would prevent the poor designs multiple inheritance would normally enable.
• A behavior could implement interfaces and inherit other behaviors, but it cannot inherit a class.
• A behavior could specify a constraint similar to a generic constraint where the class that implements a behavior must inherit a given base class.
• All protected and public members of a behavior must be overridable.

Thus, to solve the above example, a Bark behavior and Meow behavior could be defined, which implement the IBarkable and IMeowable interfaces.  Dog could inherit Bark, Cat could inherit Meow, and Human could inherit both.

Another example that comes to mind are the various WinForms control classes.  You'll notice that Form inherits ContainerControl which inherits ScrollableControl which inherits Control.  But does it logically follow that every container control is also scrollable?  What if the container and scrollable capabilities were implemented as behaviors?  Then a control could inherit the container capabilities without inheriting scrollability, and Form could still inherit both.  Both behaviors would specify a constraint that the class must inherit Control so that they would have access to the members of the Control class.  (That would be one strong advantage over using a simple aggregate relationship instead.)

Unfortunately, I was not able to attend the PDC 2008.  But I have read some blog posts from some who attended yesterday.  It looks like C# 4.0 will support many dynamic typing concepts including co- and contra-variance, and although "duck typing" was not explicitly mentioned, it seems to be implied by what I read.  (Since duck typing is a principle of dynamic typing and not necessarily a feature in its own right, I am not surprised it is not named specifically.)

Now don't get me wrong, it was fun writing the duck typing library, but I would have no problem whatsoever if it were made obsolete by this.  Having the features integrated into C# would be awesome, and I'm sure it would eliminate the initial overhead caused by the dynamic compilation used by the duck typing library.

I think I will have to actually use C# 4.0 before I know how it will affect the usefulness of the duck typing library, but I am thinking right now that it may still be useful for interacting with "vintage" code libraries.  That, as I understand it, is actually what Jordan uses the library for most.  So whether C# 4.0 will fit the bill in this respect hinges on whether the dynamic typing features can be used when interacting with libraries that were not written or compiled in C# 4.0.

Unfortunately, I haven't had the chance to spend a lot of time working on the new duck typing library, which may actually have equaled wasted effort, but if such a library would still be useful with C# 4.0, I think it will change significantly from what I originally thought.  It will probably be designed specifically to complement C# 4.0 features.

It seems inevitable that whenever I run into problems because something isn't working right, it's because some programmer out there somewhere (whoever programmed the tool I'm working with) overlooked something obvious or made some other stupid decision.

For instance, I just finished an ASP .NET program that complements another ASP .NET program already published in my company's intranet.  So, it seemed logical to put it within that program's folder, making it a nested ASP .NET application.  Should be easy, right?  Just copy it in, make it its own application in IIS and bam, you're set.  Wrong.  Some programmer at Microsoft decided that nested ASP .NET applications should inherit all the configuration of the parent application by default (or should I say "dofault" since it's an initial setting that does cause a fault instead of preventing one).  This includes configuration that would cause dependencies to the parent's assemblies, which of course would be missing from the child's bin folder (since they have absolutely nothing to do with the child application).  And, of course, broken dependency equals completely nonfunctional application.

So I thought, "Well, this is a pain in the neck.  Now I have to tell the child application not to inherit configuration from the parent."  Wrong again!  There is actually no way to do that.  No, instead, you have to tell the parent application not to make the child applications inherit its configuration!!  I hope, I really sincerely hope that I don't have to explain what makes that a really really bad design...

Another thing I run into all the time happens when you import from Excel into SQL Server.  If a column contains some number values and some text values, making the column type textual instead of numeric, instead of converting the number values to text like any sane person would do, it omits the number values altogether!  (I would say anyone with half a brain, but I actually know of someone who had half her brain removed due to brain cancer and she's actually pretty smart.)  Guess what, I need those values too!  Otherwise, they wouldn't be there.  So the only solutions I have found are A) Manually convert every numeric value cell to a number stored as text, B) Write a Visual Basic macro to do this for you, or C) Save the spreadsheet as a CSV file and import that into SQL Server.  All of these solutions are either tedious and time-consuming or really really crude and ugly.  I hate resorting to crude methods...

So this has me wondering:  Do people purposely do stupid things?  Like, it's hard for me to imagine that these people actually think these ideas are good ideas.  I mean, they have to realize at least to some degree how stupid they are.  The only reasonable explanation that I can come up with is that implementing a good idea would require more effort up-front and they were simply too lazy for that, and since they don't care, they just went with the bad idea.  So really, it wouldn't be "stupid programmers", it would be "lazy, careless programmers".  Which is worse?  Well, "stupid" is not as bad since a "stupid" person doesn't know any better.  But a "lazy, careless" person can be held accountable because they know better.

Now for me, I simply cannot stand to do anything a certain way when I know there is a better way to do it.  Or even if I know there might be a better way to do it, then I am driven to find it.  I am always thinking of how decisions will affect the project in the long-run, always doing things now to save time on an ongoing basis later.  I won't comment on my smartness, but while I may be lazy at times, I am definitely never careless, and my carefulness at least prevents me from being lazy in a way that will affect the quality of my work.  For me to knowingly implement something stupid would be cruel and unusual torture for me.  I would be ashamed to be associated with such work.  You could not pay me to do it.  I would find a new job if I was forced to cut corners regularly.

Am I the minority?

Is it because many programmers aren't very smart or is it because they don't care?  You know, I would argue that the two are not mutually exclusive.  Since computers and software are constantly changing, you have to be constantly learning in order to succeed in this profession.  If you don't care, you won't want to learn, and you'll end up doing stupid things.  If someone were to ask me if they should enter this field, I would tell them the same thing one of my instructors in college told me.  He said, "If this is what you really love doing, and you really really want to do it for a living, then go for it.  But if you're not that into it, and you just want a job to make money, you might want to consider a different major."  I stuck with it because I live, eat, and breathe programming.  I was programming before I went to college.  I go to work and program, get home from work and program, and constantly read and learn about programming.  I do it because I love developing software and I am passionate about it.  I think that's what makes me good for this job.  It's not knowledge or skills; my current knowledge and skills will no doubt be obsolete in little more than a few years.  But I won't be because I will be continuing to learn.  So if you're a programmer who doesn't care about programming, you're going to be left behind and probably find yourself out of work.  That may be sad for you, but ultimately good for software.  But will that nature of the field be enough to weed out the careless programmers?