Generi type inheritance ????

Actualy it doesn't break any encapsulation it's just inheritance if inheritance breaks encapsulation this does too.

If it is done by the rules of inheritance it does't break encapsulation . It can't.     How?

And btw MyClass<String> it should't be ilegal because String is a sealed class.

so If

class MyClass : string {  // not legal 'String' is sealed class
}
VS Error :
"Error 1 'Testing.MyClass': cannot derive from sealed type '"

so should be :

MyClass<String> instance; 


I don't see any where your objections are coming from.

I dind't try to sugest a way to break encapsulation but a way to construct a generic type that subclases another type at use time.

And I'm not sugesting any new features or anithing that can't be done with curent language and platform features

I'm, not talking about mixins , they are slithly diferent than what I mean. I don't just want an agregation of fields and methods created from clases.

Also what I'm saying is not like "Multiple Inheriance" at all, the new classes still have a single inheritance path

for my previouse example :

class MyClass<T> : T {
}

MyClass<Employ> is a subclass o Employ and that's is his type is

typeof (MyClass<Employ>) wich IS an Employ derived type


also MyClass<Company> is a Company type and the only conection to MyClass<Employ> could be the fact that they both are objects


Also i thing the same constraigt system could be applied for "this" reference inside the generic class

TomasDeml wrote:

AndyC wrote: You can solve this sort of problem with Multiple Inheritance, C# doesn't support this although the CLR does. I think only C++ provides it at the moment.

What? CLI (and IL) supports multiple inheritance? Since when? If I missed something, correct me...

CLI doesn't support multiple inheritance, but Eifel DotNET DOES! ( ... some fishy workaround using interfaces ofc)

leeappdalecom wrote:

This is something like recursive generics lol

Your saying a container class that is the same type as the type it consumes?

I dont actually see a use for this apart from recursively creating a data structure that can consume itself.  Why would you need this?

I'll give you a clear 'simplified' example :

I have an aplication that is modulary built and pases entities (Class instances of type Entity) between modules in a loosely coupled fashion through a service.

Those entities are in the order of hundreds.

The thing is that over time for some entities there was the need to store snapshots them (an sorth of undo capability)

So the chosen path here was for those entities to implement the
"ISnapshot" interface. Wich meant subclassing and Implementing the interface or just implementing without sublasing

The thing is that the implementation is not dependent of the entities internal working. Is the same implementation over and over for every entity.

It has a StoreSnapshot method that basicaly clones the entity and store'it along with some other info.

So for this particular type of problem :
 - either write the same code (Copy Code) for every entity manualy - (VB6 Style)
- either use a for of automation like VB Scripts to implement the interfaces
- either use some sort of code generator

to do basicaly the same thing . Implement an Interface on a type tha't not dependent of the types's topology.

And the rezult was hundreds of identical implementations of the interface.

The other aproach would have been to create a Container Class to store the entities. But this could't be accomplished because :

- first of all a new service that passed container clases around had to be created to pas the new containe objects storing also the enties them selves and the snapshot data.

- The entities travel through diferent modules, some of wich are not interested in the snapshot capabilies of the entities so containers could'n be passed to them only entities. And it wasn't desired make those modules aware of the new type only for passing it arround.

- An module that dind't knew about the snapsot could't just recive an entity without container because he coul pass it to a module thar recognizes it and need it but that info would have been los.


I realy hope I managed to create a picture here ...

All this would have been infinitly more simple if

I could do this :

class Snapshot<T> :  T, ISnapshot where T : Entity {

}

and just modify my factory class to create Snapsot entities ould have solvel my problem in 5 mins not days , not to mention maintanace or the posibility of refactoring.

leeappdalecom wrote:

Ok i think i see what your saying. One thing springs to mind how would you store these snapshot objects without a container object?

If you modify your enitity to be a container then it wont be an entity anymore.

I dont see why you cant use the BindingList<> class to do something similar.

(tell me if i totally got the wrong end of the stick lol)

storing them is't a problem the problem is providing new capability and being able to still use the same objects using the old infrastructure.

also BindingList<T> is a colection class for use with GUI's  maingly not need for its capabilitties here

leeappdalecom wrote:

wait it's all just made sense now lol

Inherit and extend the capabilities of different types using generics rather than extending every type you have created and it still be the same type of object in the end.

Exactly! after all this is what generics are all about provide a generic implementation that is specialised at use time.


So my ipothetical class could become :

class Snapshot<T> : T , ISnapshot<T> 
 where T : ICloneable
 {
      private T _snapshot;

      Public T SnapShot {
            get {
                  return _snapshot;
            }
      }
      
      public void SaveSnapshot() {
            _snapshot = this.Clone();
      }
}

what you get is your types are extensible in a generic way and also
specialised without "code copy"

So if anyone is interested to see this feature in a future version of dot Net framework there is an open Sugestion on Microsoft's feedback center wich can be voted for


http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=f2b1c45b-4be4-410d-8d4b-84315730cea6


My thanks to the community

SnapshotBase snapshotInstance = new Snapshot<SnapshotBase>();

snapshotInstance.SomeMethod1();
snapshotInstance.SomeMethod2();
this shoud call the SnapshotBase's methods


((Snapshot<SnapshotBase>) snapshotInstance).SomeMethod1();
((Snapshot<SnapshotBase>) snapshotInstance).SomeMethod2();

should call Snapshot<SnapshotBase>'s methods just like in a normal inheritance scenario
I'm not sugesting any oop rules breaking. I've told you before this shudn't replace non virtual methods using this tecnique.

I don't realy know why you understood it like that.


this is Exacly how my Generic class should behave, like a normal inherited class

using System;

using System.Collections.Generic;

using System.Windows.Forms;

namespace Testing {

static class Program {

static void Main(string[] args)

{

      BaseClass bc = new Class2();

      bc.Write();

     ((Class2)bc).Write();

      Console.ReadKey();
}
}
public class BaseClass {
   public void Write() {
      Console.WriteLine("1");
   }
}
public class Class2 : BaseClass {
   public void Write() {
      Console.WriteLine("2");
   }
}

}

Results :

1
2

[EDITED]

So what's your objection realy ???

the fact that the compiler doest't isues a warning for my class, it can just as easily isue a warning if it gets implemented ...

the code works even it's just a warning , something to be aware of. and if you instantiate a
Snapshot<SnapshotBase>  sn = new Snapshot<SnapshotBase>() you should be fully aware of the fact that you're using the instantiated' class methods primarely or if you want to use the base class' methods you can cast. Or maybe there's anothe way around this to be sure all of the time what method you are calling.

Maybe generic clases that extend other types should't even be allowed to have non virtual or non explicit interface methos. The best way can found to solve this.

But I don't see why generics cand be brought to the next level by parametrising more of their elements.

Generics started a new programing paradigm parametrisable code. And it should keep evolving and not stop right here.

I' dont see any benefits from stoping.