Advanced Records und überladene Operatoren

[Patito]

Ein paar Links zu Leuten die objects gut finden:

"http://blog.synopse.info/post/2010/08/06/Save-object,-stop-class-hegemony!"
http://stackoverflow.com/questions/6103 ... -in-delphi

Mit Stack-basierten Objekten kann man sich Overhead ersparen und Vererbung ist eben manchmal nützlich.
(Vererbung ist eben mit eines der Hauptfeatures der OO. Ohne Vererbung kann man zwar sicher auch leben,
es ist aber eben nicht dasselbe ...)

[theo]

Ich habe nichts gegen Objects, aber ich halte mich an die Empfehlungen.
Aus deinem Link:

The "object" type is deprecated. As was said, it mainly exists for compatibility with old Turbo Pascal. That is why it is not documented very well. It's use is not promoted.

While I can appreciate the problems caused when something like this breaks
existing code, and/or what you see as advantages to the old format, the fact
is everyone has had 15 years so far to get off the old object type. The
old type has been deprecated and actively discouraged since the intro of
Delphi. While Delphi has been amazingly backward compatible over the years,
including with this, how long is long enough?

To resurrect the old object type would mean three types of "objects"
actively supported and documented (not even counting interfaces).

While instantiating classes does have a bit of overhead comapred to the old
type, I have never found an case where it made any significant difference in
the performance of anything I've written, and even then there are ways to
improve that - pre-allocating, caching, pooling. etc. There is even a way to
allocate space for multiple class instances in one go if you really need
to try to squeeze out a few more cycles.

Depending on what you are doing, you could possibly have a singleton class
instance managing an array of records, putting an "OO" face on them.

IMHO, objects were rightly deprecated with the intro of Delphi and, given
that there are plans underway to introduce a new compiler before too long, I
personally hope they, once and for all, omit old-style objects from the new
implementation.

Klar, man kann sagen: "Was geht uns die Delphi Strategie an?"
Aber irgendwie machen diese Aussagen keine Lust auf Object.

[mse]

Klar, man kann sagen: "Was geht uns die Delphi Strategie an?"
Aber irgendwie machen diese Aussagen keine Lust auf Object.

Naja, Rudy Velthuis ist nicht gerade "die" objektive Delphi Referenz.

[theo]

Naja, Rudy Velthuis ist nicht gerade "die" objektive Delphi Referenz.

Vielleicht nicht, aber dass die Objects bei Delphi stiefmütterlich behandelt werden, kann man schon erkennen.
Zeitweise gingen die auch gar nicht richtig: http://qc.embarcadero.com/wc/qcmain.aspx?d=71723

[marcov]

Ein paar Links zu Leuten die objects gut finden:
"http://blog.synopse.info/post/2010/08/06/Save-object,-stop-class-hegemony!"

Alle Gründe der er nennt funktionieren auch mit Advanced Records.

http://stackoverflow.com/questions/6103 ... -in-delphi

Der einige "pro" Turbo Objekte Poster ist denselben als den ersten Link. Vererbung wird nicht genannt.

Mit Stack-basierten Objekten kann man sich Overhead ersparen

Im Praxis nur sehr wenig. Mann bemerkt dies nur mit Millionen Objekten.

und Vererbung ist eben manchmal nützlich.

Aber Turbo Objekts Vererbung ist NICHT sehr nutzlicht in Kombination mit stack based. Funktioniert nur wenn mann mit pointer (heapbased )arbeitet. Beispiel:

Code: Alles auswählen

Type  TChild= object (Tancestor)
                     field : integer;
                       procedure bla; virtual;  // virtual=override im TP dialekt 
                      end;
 
  procedure xx;
   var 
       yy  : TAncestor;
   begin
     yy:=etwas_tchild;  //NICHT MOEGLICH, weil TChild grosser ist als TAncestor!
     yy.bla;
  end;

(Vererbung ist eben mit eines der Hauptfeatures der OO. Ohne Vererbung kann man zwar sicher auch leben,
es ist aber eben nicht dasselbe ...)

Aber es ist nicht das wir ohne Vererbung gehen. Wir haben schon Vererbung in Classes, und stack objekte ohne Vererbung in Advanced Records. Das reicht. Der Frage ist ob die (limitierte) Vererbung in Objekte zusätzlich benötigt wird.

Den einzige Grund der ich bedenken kann ist Unterstützung von Komponenten die noch auf nicht-Advanced-records Versionen funktionieren müssen. Für FPC ist das nicht so wichtig (neuen Versionen werden meistens schnell breit akzeptiert), aber für Delphi ist das anders. Aber jedes Jahr nimmt Unterstützung von Komponenten fuer D7 (den einige wichtige <D2006 Version) etwas ab, und das wird so weiter gehen.


P.s. es gibt auch andere weisen class Instantiation Overhead niedriger zu machen (zb in objekt stores): pooling und mass instantiation. Ich glaube das ist viel nuetzlicher als Tobject misbrauchen

[mse]

Vor allem frage ich mich, warum braucht es "advanced records" wenn es bereits "objects" gibt?

[theo]

Vor allem frage ich mich, warum braucht es "advanced records" wenn es bereits "objects" gibt?

Das habe ich mich natürlich auch gefragt, und keine absolut überzeugende Antwort gefunden.
Wahrsch. hat es etwas mit Sprachhygiene oder .NET zu tun.

Ich kann dir nur sagen, warum ich den TUnistring erst mit Advanced Records gebastelt habe und nicht schon früher mit Objects:
Ganz einfach weil die in Delphi "deprecated" sind, technisch hätte es wohl auch geklappt.

[marcov]

Vor allem frage ich mich, warum braucht es "advanced records" wenn es bereits "objects" gibt?

Vor allem denke ich man wollte die Vererbung los werden. Zweitens musste wahrscheinlich den (TP)objekt relatierte Kode ganz herschrieben werden. Tobjekt unterstuzt noch immer keine dynamische Typen in Delphi. Records unterstutzten das schon und die Kode war mehr gepflegt denke ich.

[marcov]

Ich kann dir nur sagen, warum ich den TUnistring erst mit Advanced Records gebastelt habe und nicht schon früher mit Objects:
Ganz einfach weil die in Delphi "deprecated" sind, technisch hätte es wohl auch geklappt.

Nein, weil TUniStringInternal ein automatisch Typ ist, und die sind von Delphi nicht unterstützt in Objekte. (und FPC hat das nur relativ kurz her gelöst)

[theo]

Nein, weil TUniStringInternal ein automatisch Typ ist, und die sind von Delphi nicht unterstützt in Objekte. (und FPC hat das nur relativ kurz her gelöst)

Ah, danke! Das wusste ich nicht.
Ich sagte ja, dass ich von TP Object wenig Ahnung habe.

[theo]

Aber noch eine andere Frage zu Advanced Records:
Wie kann ich da am besten Werte vorbelegen (defaults), ohne dass der Benutzer dafür eine Methode aufrufen muss?

Also ich möchte z.B. ein Integer-Feld auf 1 setzen oder so.

[marcov]

Aber noch eine andere Frage zu Advanced Records:
Wie kann ich da am besten Werte vorbelegen (defaults), ohne dass der Benutzer dafür eine Methode aufrufen muss?

Also ich möchte z.B. ein Integer-Feld auf 1 setzen oder so.

Wie Classes, nichts ohne Konstruktor.

[theo]

Wie Classes, nichts ohne Konstruktor.

Danke für die Antwort.
Schade, das ist natürlich nicht so praktisch, zumal Records afaik überhaupt nicht initialisiert sind, d.h. man kann nicht mal von 0/false ausgehen, oder?

[marcov]

Wie Classes, nichts ohne Konstruktor.

Danke für die Antwort.
Schade, das ist natürlich nicht so praktisch, zumal Records afaik überhaupt nicht initialisiert sind, d.h. man kann nicht mal von 0/false ausgehen, oder?

Nur automatischen Typen werden initialisiert mit ihre Standardwert (typisch mit Nullwerte initialisiert, also nicht vom Programmer konfigurierbar)

[pluto]

Klingt nicht schlecht. Ich habe einige male mal Operatoren überladen... kann man auch neue einfügen?

Advanced Records gefallen mir.... von den was ich hier gelesen habe.... gibt es noch mehr neue Sachen?