How I started to really understand generics

re: How I started to really understand generics

Robin — Tue, 19 Aug 2008 18:40:36 GMT

That little bit about the typed exceptions is really cool. I already have ideas as to how to use this.

re: How I started to really understand generics

Jacob — Tue, 19 Aug 2008 19:38:17 GMT

Have you considered returning InvalidOperationException<TCommand> (rather than void) from the extension method? Then your callsites become:

"throw this.NewInvalidOperationException(...);"

The nice thing with that pattern is that the debugger callstack ends up in the right place (on break when thrown) rather than one method too deep.

re: How I started to really understand generics

Kirill Osenkov — Tue, 19 Aug 2008 20:54:15 GMT

Jacob - that sounds like a good idea :)

re: How I started to really understand generics

Balaji — Sat, 30 Aug 2008 16:46:42 GMT

A nice post kirill... Never knew of such "Typed" Exceptions :-)

re: How I started to really understand generics

Darren Clark — Mon, 08 Sep 2008 23:56:51 GMT

In the "interesting usage of generics" thread I'll add this pattern:

Note that this is a made up example and I know there's better ways to do what it does, but it's just an example. The pattern is useful whenever you have a generic factory class, not just XmlSerializer.

public class MyBase<T> where T:MyBase<T>

{

private static XmlSerializer serializer = new XmlSerializer(typeof(T));

protected virtual AfterDeserialization()

{

}

public static T CreateFromXml(Stream stream)

{

T newObj = (T) serializer.Deserialize(stream);

newObj.AfterDeserialization();

return newObj;

}

Basically the idea is that you can have a single generic base class implement a factory pattern for multiple derived classes.

It also points out another interesting thing about generics. Static members on a generic class are PER T.

Using a pattern like this you have to make sure you understand what that means.

You CANNOT properly do

MyDerivedA: MyBase<MyDerivedA>

{

}

and

MyDerivedB: MyDerivedA

{

}

Since the call to MyDerivedB.Deserialize will use the same serializer as MyDerivedA, resulting in a typecast error.

re: How I started to really understand generics

madduck — Tue, 09 Sep 2008 14:17:50 GMT

How does 'class MyGenericType<T> : T' lead to multiple inheritance?

re: How I started to really understand generics

Wiebe — Tue, 09 Sep 2008 14:47:49 GMT

Hi Kirill,

thank you for the article, but I fail to see what this way of using generics improves.

Why not just add the ThrowInvalidOperationException method to the Command class, and instantiate the exception with this.GetType()? That's just as safe...

Marking it virtual would even allow you to override the behavior in derived commands where the extension/static method approach doesn't...

Additionally, I don't see the advantage of adding extension/(static) methods to classes that you have created yourself, or am I missing the point here?

Sorry I don't mean to be negative but I think you've found a complex solution to a simple problem :)

re: How I started to really understand generics

Darren Clark — Tue, 09 Sep 2008 22:59:17 GMT

The advantage of using extension methods there is that the "this" is the most derived type when it is used.

Funny enough you could use the pattern I outlined above as well.

Where you have Command<T> where T:Command<T>

Then you have CopyCommand: Command<CopyCommand> etc.

and finally void ThrowInvalidOperationException<T>(message)

I like the extension method pattern much better though since it elegantly supports more than one layer of derivations. With mine you'd end up having:

Command<T> where T: Command<T>

CopyCommandBase<T>: Command<T> where T:CopyCommandBase<T>

CopyCommand: CopyCommandBase<CopyCommand>

SpecialCopyCommand: CopyCommandBase<SpecialCopyCommand>

Note you can't directly derive SpecialCopyCommand directly from CopyCommand. If you do then all the T's will reference CopyCommand, NOT the most derived as you wanted.

re: How I started to really understand generics

Damon Wilder Carr — Wed, 10 Sep 2008 04:12:38 GMT

uhh....

public abstract class Command<T> : ICommand<Object>

where T : Command<T>, ICommand<Object>

{

public virtual void Execute() {

throw new NotImplementedException();

}

protected InvalidOperationExceptionTyped GetException(String message) {

return new InvalidOperationExceptionTyped(this, message);

}

#region Nested type: InvalidOperationExceptionTyped

public class InvalidOperationExceptionTyped : InvalidOperationException {

private readonly Command<T> _typeUsed;

public InvalidOperationExceptionTyped(Command<T> typeUsed, string message)

: base("Type was " + typeUsed + " message was " + message) {

_typeUsed = typeUsed;

}

public Command<T> CommandType {

get { return _typeUsed; }

}

#endregion

object ICommand<object>.Instance {

get { return Instance; }

}

public Command<T> Instance

{

get {

return this;

}

void ICommand<object>.Execute() {

Execute();

}

public class CopyCommand : Command<CopyCommand>

{

public override void Execute()

{

throw GetException("Something went wrong");

}

public abstract class CutCommandBase : Command<CutCommandBase>

{

public abstract override void Execute();

}

public abstract class CutCommandShapeBase : CutCommandBase {

public abstract override void Execute();

}

public class CutCommandShapeCircle : CutCommandShapeBase

{

public override void Execute() {

throw GetException("THis is a little crazy I admint");

}

public class CutCommandPoint : CutCommandBase

{

public override void Execute()

{

throw GetException("Something went wrong");

}

public interface ICommand<T> {

T Instance { get; }

void Execute();

}

P.S. This is a joke (grin)..

damon

re: How I started to really understand generics

Gareth Watson — Thu, 11 Sep 2008 17:47:13 GMT

This was an ace article!

What this means for us is that our DAL which using interfaces fill objects with data from our datastore. We were using ArrayLists because it was impossible to declare a list of interfaces and then add objects that implement that interface to it.

The method described above now allows be to get a List<T> passed then I can restrict to making sure that T implements a certain interface. Then create new T's and add them to the list!

Thanks very much for this! It's going to save us loads of code and will probably be more efficient too. Win-Win not often you get that.

re: How I started to really understand generics

Alec — Thu, 11 Sep 2008 19:28:20 GMT

So what is the difference between these two?

class MyType<T> : IEquatable<T> and

class MyType<T> where T: IEquatable<T>

re: How I started to really understand generics

David Nelson — Thu, 11 Sep 2008 22:01:36 GMT

Alec,

In the first definition, MyType<T> implements IEquatable<T>. In the second MyType<T> does not implement IEquatable at all; rather it requires that T implement IEquatable<T>, presumably so that it MyType<T> can call members of IEquatable<T> in its definition.

re: How I started to really understand generics

Kirill Osenkov — Mon, 15 Sep 2008 09:22:53 GMT

Darren: you essentially constrain the type parameter to be a derived type - that's really cool!

madduck: I updated the post, thanks.

Wiebe: this approach improves over the following:

1. I'm not modifying the Command types at all, the extension method is a mix-in (the base class Command can even be in a separate assembly, and I don't need to change it).

2. If I instantiate the exception with this.GetType(), I get runtime type information, but not compile-time. In the exception handling logic we're having, it's important to preserve static typing, which GetType() doesn't have.

3. Marking it virtual would mean more work to do in every derived class.

4. The advantage of adding extension methods to my own code is better separation of logic and promotes decoupling. Such code is more flexible and I can easily apply extension methods to newly introduced types without doing any extra work in the types themselves. This is what I call orthogonal code, and orthogonal code is pure goodness.

5. You're not negative, your critique is great and very polite. I agree that my solution might be complex, but this works great for me and my team - I don't force you to use it. This is just a hint of what you can do with the language - maybe you can use a similar trick somewhere else. I used the exceptions example just for an example of the technique.

Damon: that's hardcore!

Alec: it helps to think of a container type such as List<T>. The line List<T> : IEquatable<T> imposes the constraint on the container type itself, whereas the line List<T> where T: IEquatable<T> imposes the constraint on the element type in the container.

Thanks everyone!

More comments on generics

Kirill Osenkov — Mon, 15 Sep 2008 10:30:13 GMT

Here are some more unsorted thoughts on generics to continue this post (which has some interesting comments

re: How I started to really understand generics

Barry Wimlett — Thu, 18 Sep 2008 13:24:41 GMT

Quote:

Let's consider another insight: what's the difference between:

class MyType<T> : IEquatable<T> and

class MyType<T> where T: IEquatable<T>

If you immediately grasped what's going on, then good. Because it takes me a while to understand what's going on. Thinking about this difference made another aspect of generics clearer for me: with generics, there are always at least two different types involved: the actual type and the generic type parameters.

</Quote>

The thing is I din't grasp what is going on, and you failed to explain it, you just ploughed on with the next example.

Ay chance you could explain further so the rest of us can catch up ?

re: How I started to really understand generics

Kirill Osenkov — Fri, 19 Sep 2008 09:53:30 GMT

Alec, Barry,

I've updated the post with some more explanations regarding

class MyType<T> : IEquatable<T> and

class MyType<T> where T: IEquatable<T>

Please don't take those examples as real-life - they are very contrived and only serve the purpose of explaining stuff about generics, type parameters and constraints.

Feel free to ask more questions.