Generic Type Parameter is a Generic Type

H

Heath

I'd like to declare my class as this (but cannot):

public sealed class ScheduleList<T> : ICollection<T> where T : Schedule<U>

My abstract:

public abstract class Schedule<T> : IDateSpan, ISchedule<T>,
INotifyPropertyChanged

And a few concrete classes like this:

public sealed class TypeASchedule : Schedule<TypeA>
public sealed class TypeBSchedule : Schedule<TypeB>
public sealed class TypeCSchedule : Schedule<TypeC>

and would like to make their collections via:

new ScheduleList<TypeASchedule>();
etc.

Back to ScheduleList<>, I can of course do this:

public sealed class ScheduleList<T, U> : ICollection<T> where T : Schedule<U>

but that seems redundant to have to do:

new ScheduleList<TypeASchedule, TypeA>();

Is there any way to make a Generic Type the Generic Type Parameter without
that redundant declaration? Thanks.
 
J

Jeroen Mostert

Heath said:
I'd like to declare my class as this (but cannot):

public sealed class ScheduleList<T> : ICollection<T> where T : Schedule<U>

My abstract:

public abstract class Schedule<T> : IDateSpan, ISchedule<T>,
INotifyPropertyChanged

And a few concrete classes like this:

public sealed class TypeASchedule : Schedule<TypeA>
public sealed class TypeBSchedule : Schedule<TypeB>
public sealed class TypeCSchedule : Schedule<TypeC>

and would like to make their collections via:

new ScheduleList<TypeASchedule>();
etc.

Back to ScheduleList<>, I can of course do this:

public sealed class ScheduleList<T, U> : ICollection<T> where T : Schedule<U>

but that seems redundant to have to do:

new ScheduleList<TypeASchedule, TypeA>();

Is there any way to make a Generic Type the Generic Type Parameter without
that redundant declaration? Thanks.
Nope. You could have

public sealed class ScheduleList<T> : ICollection<Schedule<T>>

but there is no way to enforce the list type to be more specific except
through run-time checks. You have to ask yourself whether you really *need*
the list type to be that specific, though. If "TypeASchedule" is just a
shorthand for "Schedule<TypeA>" (introducing no new members of its own)
there's no point.
 
H

Heath

Thanks, J. I had considered your suggestion as well but was hoping there was
something I was missing. Unfortunately, the implementations of Schedule<T>
do have additional members unique to each. I suppose I don't HAVE to limit
it that much, but I like locking these down to what is absolutely necessary.
I will probably have to stick with run-time checks. Thanks!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top