Tech Off Thread

22 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Generi type inheritance ????

Back to Forum: Tech Off
  • User profile image
    CatalinPop

    Anyone at Microsoft ever considered to include generic type inheritance in the next release?

    What I mean is someting like this :

     class MyClass<T> : T {
    }

    where the inheritance chain is chosen when the type is constructed.

    I personaly forsee this to be very useful and i'll give a small example : 

    Let's say an ipothethical scenario where I want to give an arbitrary class the ability to store state and snapshot info. Ofcourse I could do this by simply subclasing it or create a generic class to be a container ofering those capablities, but :

             - in the first case the same implemetation must be done for every new type (Copy code)

             - in the second case the ineritance chain is lost so the container type can't be used in place o the actual type.

    Other useful usages caul be somethin like DataTable<Person> or DataTable<Company> where the DataTable<> type ads an ItemArray property, and RowVersionPropery etc. an actualy makes extens the class so it can be added to an datatable ...

    Anyone else had those kind of ideeas before?

  • User profile image
    footballism

    Pop Catalin Sever wrote:

     class MyClass<T> : T {
    }

    This is really a bad and implausible idea, you know, when you can do type inheritance this way:
    class MyClass<T> : T {
    }

    Which means that you can also legitimately do this:
        MyClass<String> genericString = new MyClass<String>();
    So the MyClass<String> can derive from String, which breaks the encapsulation of OOP, and what's more, this idea can potentialy result in some security issues.
        So never never think about this stupid idea any more.

    Sheva

  • User profile image
    AndyC

    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.

  • User profile image
    teis

    I was at a meeting in Copenhagen where Anders Hejlsberg refered to this as "mixins". They are quite useful for UI frameworks where you may want a window that inherits behavior and/or styling from several utility classes. In C++ one might use multiple inheritance to solve this, but mixins is somewhat cleaner. Actually the discussion about mixins sprang from a question about why C# didn't support multiple inheritance. Anders also said that while we would not get multiple inheritance, he might consider mixins...

  • User profile image
    CatalinPop

    Actualy it doesn't break any encapsulation it's just inheritance Smiley 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

  • User profile image
    CatalinPop

    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



  • User profile image
    TomasDeml

    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...Smiley

  • User profile image
    CatalinPop

    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! Smiley ( ... some fishy workaround using interfaces ofc)

  • User profile image
    Lee_Dale

    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?

  • User profile image
    AndyC

    TomasDeml wrote:


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


    I thought I read somewhere that it did... apparently not... my bad. Perplexed

  • User profile image
    CatalinPop

    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 ... Smiley

    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.








  • User profile image
    Lee_Dale

    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)

  • User profile image
    CatalinPop

    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

  • User profile image
    Lee_Dale

    Pop Catalin Sever wrote:
    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


    sorry i think im confused at what your trying to acheive

  • User profile image
    Lee_Dale

    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.

  • User profile image
    CatalinPop

    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"

  • User profile image
    CatalinPop

    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

  • User profile image
    footballism

    Okay, you still hold up to your ground, dude:O
    Then how do you overcome this situation:

    public class SnapshotBase
    {
        public Int32 SomeMethod1()
        {
        }
        public Int32 SomeMethod2()
        {
        }
    }

    public class Snapshot<T> : T
    {
        public Int32 SomeMethod1()
        {
        }
        public Int32 SomeMethod2()
        {
        }
    }

    So now, I have SnapshotBase and Snapshot<T> defined, then if I do something like the following in code:
    SnapshotBase snapshotInstance = new Snapshot<SnapshotBase>();

    snapshotInstance.SomeMethod1();
    snapshotInstance.SomeMethod2();

        then, up to this point, which methods will be called, those in SnapshotBase or those in Snapshot<SnapshotBase>?
    As a common sense, we all believe the methods in the base will be called, because we actually use the base class reference to call the methods, and because the derived class reimplement the methods defined in the base(hide by signature), and those methods has nothing to do with those in the base, that is to say polymorphism doesn't work here. now the problem comes, because Snapshot<SnapshotBase> is derived from SnapshotBase, it should inherit the public contracts of its base, but the above sample code doesn't work that way. so if we have generic type derived from its type parameter which is exactly what you proclaim, then the fundamental principle of OOP is violated.

    Sheva


Conversation locked

This conversation has been locked by the site admins. No new comments can be made.