Anfägerfrage: "Vererbung von Typen?"

[p80286]

Ja ist blöd formuliert aber mir fällt nichts besseres ein.
Es geht darum das ich eine von TList abgeleitete Basisklasse habe, die Dateiinformationen aus TSearchrecord verwaltet. Nun möchte ich noch weitere Informationen, z.B. Prüfsummen dazu packen. als record sieht das ganz einfach aus, aber wie kann ich das "sauber" über Vererbung lösen?

Delphi-Quellcode:

tMyrecord = record
              Name:string;
              Pfad:string;
              Size:LongWord;
            end;
tMyrecord2 = record
              Base:TMyrecord;
              PSa:Tpsa;
              PSb:TPSb;
end;

TmyList1= class (Tlist)
  protected
    function Get(Index: Integer): t_Myrecord;
......
end;

TmyList2= class (tmyList1)
 function Get(Index: Integer): ?????????
end;

Generics sind keine Möglichkeit, da ich max. D2006 zur Verfügung habe.

Gruß
K-H

[DeddyH]

Wenn Du aus den Records Klassen machst, kannst Du doch auch wieder ableiten, die Funktion gibt dann eben den Elterntyp zurück.

[Pixel]

Wie DeddyH schon sagte: Aus den records Klassen machen:

Delphi-Quellcode:

tMyrecord = class
              Name:string;
              Pfad:string;
              Size:LongWord;
            end;
tMyrecord2 = class(tMyrecord)
              PSa:integer;
              PSb:integer;
            end;

In Delphi kann man records nicht vererben!

Hier ein gutes Zitat von Berry Kelly:

Zitat:

Relevant to this question, there are two kinds of inheritance: interface inheritance and implementation inheritance.

Interface inheritance generally implies polymorphism. It means that if B is derived from A, then values of type B can be stored in locations of type A. This is problematic for value types (like records) as opposed to reference types, because of slicing. If B is bigger than A, then storing it in a location of type A will truncate the value - any fields that B added in its definition over and above those of A will be lost.

Implementation inheritance is less problematic from this perspective. If Delphi had record inheritance but only of the implementation, and not of the interface, things wouldn't be too bad. The only problem is that simply making a value of type A a field of type B does most of what you'd want out of implementation inheritance.

The other issue is virtual methods. Virtual method dispatch requires some kind of per-value tag to indicate the runtime type of the value, so that the correct overridden method can be discovered. But records don't have any place to store this type: the record's fields is all the fields it has. Objects (the old Turbo Pascal kind) can have virtual methods because they have a VMT: the first object in the hierarchy to define a virtual method implicitly adds a VMT to the end of the object definition, growing it. But Turbo Pascal objects have the same slicing issue described above, which makes them problematic. Virtual methods on value types effectively requires interface inheritance, which implies the slicing problem.

So in order to properly support record interface inheritance properly, we'd need some kind of solution to the slicing problem. Boxing would be one kind of solution, but it generally requires garbage collection to be usable, and it would introduce ambiguity into the language, where it may not be clear whether you're working with a value or a reference - a bit like Integer vs int in Java with autoboxing. At least in Java there are separate names for the boxed vs unboxed "kinds" of value types. Another way to do the boxing is like Google Go with its interfaces, which is a kind of interface inheritance without implementation inheritance, but requires the interfaces to be defined separately, and all interface locations are references. Value types (e.g. records) are boxed when referred to by an interface reference. And of course, Go also has garbage collection.

[p80286]

Vielen Dank!
Dann wird ich aus meinen geliebten Records mal Klassen machen.

Gruß
K-H