Generic Collection of deferred generic types

[Steven Cummings]

Hello,

I've scoured this usenet group and didn't find anything specific to my
problem, so hopefully this won't be a repeated question. I'm all but
certain it's not.

I would like to *declare* (not just instantiate at runtime) a generic
collection whose element-type is a generic class too. But I don't want
to declare what the element-type's generic parameters are.

My best example is using the common "Pair" example. Suppose you have
the following:

public struct Pair<TFirst,TSecond>
{
public TFirst FirstValue;
public TSecond SecondValue;
}

Granted in my implementation I'm declaring a class, and I understand
struct is a value-type, so I don't know if this has any effect on my
problem, but onward...

I want to declare a collection of type ICollection<Pair> such that I
can put Pair<string,int> or Pair<uint,int> in it. I need type Pair to
be generic, but I need my collection to not care about that just yet.
The quick and dirty solution would be to not use generics for the
collection and always cast both ways, but I was wondering if anybody
could think of a better solution?

Thanks.

 

[Mattias Sjögren]

Steven,

I want to declare a collection of type ICollection<Pair> such that I
can put Pair<string,int> or Pair<uint,int> in it. I need type Pair to
be generic, but I need my collection to not care about that just yet.
The quick and dirty solution would be to not use generics for the
collection and always cast both ways, but I was wondering if anybody
could think of a better solution?

The solution is probably to move any members in Pair that you need to
use in the collection to a non-generic base class or interface that
Pair then extends (impossible in this case since it's a struct) or
implements.


Mattias

 

[Marc Gravell]

The ICollection must be typed to something, and since Pair<Class1> and
Pair<Class2> cannot cast to eachother, I can think of 2 immediate solutions:

1: base class (here using class; not sure if it would work using struct)

public class Pair {}
public class Pair<T1, T2> : Pair {} // the typed class has the properties
etc

Now you can create an ICollection<Pair>; note that it won't have much on it,
though!

2: interface

public interface IPair {}
public class Pair<T1,T2> : IPair {}

But I don't think you gain much by doing it as neither Pair nor IPair have
any interesting properties! You might as well use object (except at least
the first option ensures the type hierarchy)

Better options may be available

 

[Steven Cummings]

Thanks for the responses. Those are some of the various things I had in
mind for alternatives, but the more reading I do, the more it seems I
won't be able to get *exactly* what I'm looking for here. Not the end
of the world, just won't be able to strongly type the collection.

 

[Helge Jensen]

Thanks for the responses. Those are some of the various things I had in
mind for alternatives, but the more reading I do, the more it seems I
won't be able to get *exactly* what I'm looking for here. Not the end
of the world, just won't be able to strongly type the collection.

I want to declare a collection of type ICollection<Pair> such that I
can put Pair<string,int> or Pair<uint,int> in it. I need type Pair to
be generic, but I need my collection to not care about that just yet.
The quick and dirty solution would be to not use generics for the
collection and always cast both ways, but I was wondering if anybody
could think of a better solution?

I don't see how it would ever be possible to strongly type the
collection down to the types of elements of the Pair, since you want
those to be variadric.

 

[Steven Cummings]

Well, the idea I had is that it would be nice to have to typing force
that the elements must be Pairs. So If I have

ICollection<Pair> pairs = .... initialization .... // And this
currently can't be done.

I would still have to cast what I got out of the collection down to the
specific Pair implementation, but I still had the benefit of at least
enforcing that the elements be pairs.

Pair<string,int> pair = (Pair<string,int>) pairs["my-pair-name"];

Also it would be nice if the above were legal since casting
Pair<object,object> into whatever else isn't supposed to be legal.

I could use the subclassing mechanism, where something like PairBase
doesn't have the generics, but that seems a hefty kludge to impose on
your model just for this benefit, so it's not worth it in the end.
That's all. Like I said, not the end of the world. I'm still somewhat
new to C#'s generics, so I'm in the mode of testing it's limits.

 

[Helge Jensen]

Well, the idea I had is that it would be nice to have to typing force
that the elements must be Pairs. So If I have

ICollection<Pair> pairs = .... initialization .... // And this
currently can't be done.

Actually, that's almost what Marc Gravell suggested, isn't it?

I haven't compiled the following code, but it should (roughly) work:

public interface IPair {
object First { get; set; }
object Second { get; set; }
}
public struct Pair<T,R>: IPair {
public new T First;
public new R Second;
public Pair(T first, R second)
{ this.First = first; this.second = Second; }
public IPair.First {
get { return First; }
set { First = (T)value; }
}
public IPair.Second {
get { return Second; }
set { Second = (R)value; }
}
}

ICollection<IPair> pairs =
new ArrayList<IPair>(
new IPair[] {
new Pair<string, int>("0", 0),
new Pair<int, string>(0, "0")
});

I would still have to cast what I got out of the collection down to the
specific Pair implementation, but I still had the benefit of at least
enforcing that the elements be pairs.

Pair<string,int> pair = (Pair<string,int>) pairs["my-pair-name"];

ICollection<T> doesn't have an indexer, it has a .Contains, though.

Perhaps you are looking for an IDictionary instead? You could make a
helper-class for indexing like the above, but if you need to index by
the First property, perhaps you are better off using one of the
IDictionary implementations.

Also it would be nice if the above were legal since casting
Pair<object,object> into whatever else isn't supposed to be legal.

foreach ( IPair pair in pairs )
Console.Writeline("Got pair {0},{1}", pair.First, pair.Second);
if ( pair is Pair<string,int> ) {
object old_first = pair.First;
pair.First = "x";
Pair<string,int> typed_pair = (Pair<string,int>)pair;
string first = typed_pair.First;
int second = typed_pair.Second;
}
}

Should be legal, and run as expected.

I could use the subclassing mechanism, where something like PairBase
doesn't have the generics, but that seems a hefty kludge to impose on
your model just for this benefit, so it's not worth it in the end.
That's all. Like I said, not the end of the world. I'm still somewhat
new to C#'s generics, so I'm in the mode of testing it's limits.

Introducing a common super-type is the usual trick for getting
compile-time typed languages to do this kind of thing.

 

[Nima Hakami]

I have a similar problem with generics:

I have a generic class Field<T> which includes an event like this:

public class FieldChangeEventArgs<T> : EventArgs
{
public T OldValue;
public T NewValue;

public FieldChangeEventArgs(T oldValue, T newValue)
{
OldValue = oldValue;
NewValue = newValue;
}
}

public class Field<T> : IField
{
....
public event EventHandler<FieldChangeEventArgs<T>>
ValueChanged;
}

Now I've also a class called Entity which includes a dictionary
collection of fields. Assuming that the previous workaround help
getting the collection work fine, I still don't know how I could use
that event-handler here in the Entity class: I want to subscribe to the
FieldChanged event of all those fields in the Entity and fire an
EntityChanged event whenever a field changes.

public class Entity
{
public Dictionary<string, IField> Fields

private void SubscribeToFieldEvents()
{
foreach (IField field in Fields)
{
field.ValueChanged += new EventHandler.....?!!
}
}
}

 

[Nick Hounsome]

And IField is...............?