Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

(Semi-)Dynamic Typing with CLR 2.0 Generics?

I had some thoughts and ideas about generics, but particularly I'm curious about your takes on the above question. I've posted it in my blog at --- (I'm not advertising here, I'm looking for answers =)

Saturday, May 21, 2005

Here's an excerpt so that you know why you should click the link above :)

"I'm currently wondering whether a specific kind of "dynamic typing" that I have in mind will be possible with Generics in .NET 2.0, due Really Soon Now.

Let me explain what I have in mind. I think this would greatly increase software flexibility and programmer productivity. Perhaps it is an old idea, perhaps not---you tell me!"

Saturday, May 21, 2005

Let me first quote the *essential* part of Phil's article, not its introduction (this is an engineer-to-engineer venue, no?)

Phil writes:
We have our product categories LifeInsurance, SecondHandLifeInsurance, and HedgeFondsLifeInsurance (corresponding to A, B, and C respectively) and our interface definition ISubscription. Now a new product comes along of category LifeInsurance, but unlike most LifeInsurance products, this also needs to implement interface ISubscription. The product will be represented as an object instance, not a class! (So the root base class would be something like ProductBase.)

Instead of creating a type SubscriptionLifeInsurance that inherits from LifeInsurance and implements ISubscription (whether manually using the IDE or dynamically using reflection emit doesn't matter here), I would be able to leverage generics to do this:

LifeInsurance<ISubscription> newProduct = new LifeInsurance<ISubscription>.

Likely, the definition of the generic type would look somewhat like this:

public class LifeInsurance<T> : <T>

Looks simple, but think a moment about the implications and possibilities. Wouldn't that be great? Wouldn't this combine the best of both worlds, dynamic and static typing?

I think it would.

Now, somehow I have the feeling it won't be possible, but before checking the docs I wanted to record and share my ideas.

The mistake here is in misunderstanding that generics introduce a full-blown, first-class class.  Assuming that

public class LifeInsurance<T> : <T> { body }
public class LifeInsuranceNonGeneric { same body }
// "same" down to constructor names

the two classes will have the same properties and methods



class FooifiedLifeInsurance : LifeInsuranceNonGeneric, IFoo { }

There is one important difference, however: the former will retain all overloads of the constructor defined in LifeInsurance<>, while they have to be written explicitly in the (currently empty) body of the derived class FooifiedLifeInsurance.  If there are many overloads and  all of them are to be retained, then the generic form is preferred. However, this is only a language trick, not - if an imaginary C% language had the following form

class FooifiedLifeInsurance : withconstructors LifeInsuranceNonGeneric, IFoo { }

telling the derived class to have all the constructors of the base class, this part of the language woul be implementable in CLR of .NET 1.0.

All in all, you are only talking abour interfaces. I also do no understand why are you referring to this as dynamic, semi-dynamic or (semi)-dynamic typing. To me, it looks static as the Stonehedge.

Dr. Bogolamer Frobb
Wednesday, June 15, 2005

*  Recent Topics

*  Fog Creek Home