Feature request for C# Generic inheritence

[Ido Samuelson]

Hello,

What do you think about the following features:

public class GenericDecorator<T: T
{

}

can leverage to a few things:

public interface IChannel
{
void Connect();
void Disconnect();
}

public class TcpChannel : IChannel
{
....
}

public class ChannelDescriber<T: T where T : IChannel, class
{
public string ChannelName {get; set;}
}

another more complicated example:

public class Extender<T,K: T
{
public K Data {get;set;}
}

which can be use to :
Extender<EventArgs,stringextender;

extender.Data (give the same ability as EventArgs<Tbut more generic which can leverage other types that do not support generics.

Last is for delegates aka

delegate void extendDelegate<T,K>(K t) : T where T : delegate
// K should be added as first parameter.
and usage:

extendDelegate<ThreadStart,stringStart;

Start("hello world");

which means that even further we can do this:

System.Threading.Thread.Start(Start("ido",null)); // anonymous delegates feature

void Start(string name, object state);

you can vote for the feature in the following like:
https://connect.microsoft.com/Visual...&wa=wsignin1.0
--
Best,

Ido Samuelson

[Ben Voigt [C++ MVP]]

The trouble is that .NET generics, unlike C++ templates, are completely
compiled in generic form. However, all base classes must be known at
compile time. Only C++ templates, which are made concrete before being
compiled, can inherit from template parameters. However .NET classes can
use the curiously recurring template pattern which has some overlapping
applications.

"Ido Samuelson" <is********@nana.co.ilwrote in message
news:4C**********************************@microsof t.com...
Hello,

What do you think about the following features:

public class GenericDecorator<T: T
{

}

can leverage to a few things:

public interface IChannel
{
void Connect();
void Disconnect();
}

public class TcpChannel : IChannel
{
....
}

public class ChannelDescriber<T: T where T : IChannel, class
{
public string ChannelName {get; set;}
}

another more complicated example:

public class Extender<T,K: T
{
public K Data {get;set;}
}

which can be use to :
Extender<EventArgs,stringextender;

extender.Data (give the same ability as EventArgs<Tbut more generic which
can leverage other types that do not support generics.

Last is for delegates aka

delegate void extendDelegate<T,K>(K t) : T where T : delegate
// K should be added as first parameter.
and usage:

extendDelegate<ThreadStart,stringStart;

Start("hello world");

which means that even further we can do this:

System.Threading.Thread.Start(Start("ido",null)); // anonymous delegates
feature

void Start(string name, object state);

you can vote for the feature in the following like:
https://connect.microsoft.com/Visual...&wa=wsignin1.0
--
Best,

Ido Samuelson

[Ido Samuelson]

This is correct. I thought that for generic inheritance, the compiler will
create an explicit type at compile time. Same way anonymous method works.

"Ben Voigt [C++ MVP]" <rb*@nospam.nospamwrote in message
news:#o**************@TK2MSFTNGP02.phx.gbl...

The trouble is that .NET generics, unlike C++ templates, are completely
compiled in generic form. However, all base classes must be known at
compile time. Only C++ templates, which are made concrete before being
compiled, can inherit from template parameters. However .NET classes can
use the curiously recurring template pattern which has some overlapping
applications.

"Ido Samuelson" <is********@nana.co.ilwrote in message
news:4C**********************************@microsof t.com...
Hello,

What do you think about the following features:

public class GenericDecorator<T: T
{

}

can leverage to a few things:

public interface IChannel
{
void Connect();
void Disconnect();
}

public class TcpChannel : IChannel
{
...
}

public class ChannelDescriber<T: T where T : IChannel, class
{
public string ChannelName {get; set;}
}

another more complicated example:

public class Extender<T,K: T
{
public K Data {get;set;}
}

which can be use to :
Extender<EventArgs,stringextender;

extender.Data (give the same ability as EventArgs<Tbut more generic
which can leverage other types that do not support generics.

Last is for delegates aka

delegate void extendDelegate<T,K>(K t) : T where T : delegate
// K should be added as first parameter.
and usage:

extendDelegate<ThreadStart,stringStart;

Start("hello world");

which means that even further we can do this:

System.Threading.Thread.Start(Start("ido",null)); // anonymous delegates
feature

void Start(string name, object state);

you can vote for the feature in the following like:
https://connect.microsoft.com/Visual...&wa=wsignin1.0
--
Best,

Ido Samuelson

[Jon Skeet [C# MVP]]

Ido Samuelson <id***********@gmail.comwrote:

I know how the compiler works for the current generics. I was talking about
how it "will" work for the feature request. So for generic inheritance an
explicit code generated type will be created at compile time. This will
resolve the v-table issue because the base class will be known exactly.

so for your example

class Gen<T: T where T : IList
{
int IList.Count { get { ... } }
}

at runtime a new type will be created:

Class GenXXXList : List
{
int IList.Count { get {... } }
}

and all the code refered to Gen<Twill be replaced with GenXXXList. (same
way as anonymous methods)

So a Gen<Listused in one assembly wouldn't the same type as a
Gen<Listin another assembly? Sounds like a recipe for hard-to-
diagnose bugs.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Ido Samuelson]

isn't that the same case with anonymous methods or extension methods? in
some cases both can cause unexpected behaviors.
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP*********************@msnews.microsoft.com. ..

Ido Samuelson <id***********@gmail.comwrote:

>I know how the compiler works for the current generics. I was talking
about
how it "will" work for the feature request. So for generic inheritance an
explicit code generated type will be created at compile time. This will
resolve the v-table issue because the base class will be known exactly.

so for your example

class Gen<T: T where T : IList
{
int IList.Count { get { ... } }
}

at runtime a new type will be created:

Class GenXXXList : List
{
int IList.Count { get {... } }
}

and all the code refered to Gen<Twill be replaced with GenXXXList.
(same
way as anonymous methods)

So a Gen<Listused in one assembly wouldn't the same type as a
Gen<Listin another assembly? Sounds like a recipe for hard-to-
diagnose bugs.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Ido Samuelson]

Further, it is never a good idea to have the same class name, same type and
same namespace in different assemblies. So I really don't see a problem in
debugging.

"Ido Samuelson" <id***********@gmail.comwrote in message
news:ea**************@TK2MSFTNGP06.phx.gbl...

isn't that the same case with anonymous methods or extension methods? in
some cases both can cause unexpected behaviors.
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP*********************@msnews.microsoft.com. ..

>Ido Samuelson <id***********@gmail.comwrote:

>>I know how the compiler works for the current generics. I was talking
about
how it "will" work for the feature request. So for generic inheritance
an
explicit code generated type will be created at compile time. This will
resolve the v-table issue because the base class will be known exactly.

so for your example

class Gen<T: T where T : IList
{
int IList.Count { get { ... } }
}

at runtime a new type will be created:

Class GenXXXList : List
{
int IList.Count { get {... } }
}

and all the code refered to Gen<Twill be replaced with GenXXXList.
(same
way as anonymous methods)

So a Gen<Listused in one assembly wouldn't the same type as a
Gen<Listin another assembly? Sounds like a recipe for hard-to-
diagnose bugs.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Ido Samuelson <id***********@gmail.comwrote:

Further, it is never a good idea to have the same class name, same type and
same namespace in different assemblies. So I really don't see a problem in
debugging.

It's completely different to that situation. It's perfectly reasonable
to use List<stringin two different places, but your way of working
would break it. If I were to declare an API of

public Gen<StreamGetGen()

then the object returned by the method wouldn't be usable in a
different assembly.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Ido Samuelson <id***********@gmail.comwrote:

isn't that the same case with anonymous methods or extension methods? in
some cases both can cause unexpected behaviors.

No - anonymous methods are only accessed within the same type, and
extension methods are completely different anyway.

Anonymous *types* are consistent within an assembly, but that's mostly
an optimisation - you can't expose an API in terms of anonymous types.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too