CLEAR zu verwenden, wobei die gute Frage ist warum das uneindeutig sein soll, dass kann man eher über REFRESH sagen, hängt schlicht mit Vereinheitlichung zusammen, da CLEAR für alle Arten von Variablen verwendet wird.DeathAndPain hat geschrieben: ↑24.10.2024 15:08
Genauso sagt REFRESH nichts anderes aus als "Leere die folgende interne Tabelle". Weshalb man stattdessen den weniger eindeutigen Befehl CLEAR verwenden muss, erschließt sich mir nicht. Wenn ein Entwickler ernsthaft nicht mehr weiß, was REFRESH bedeutet, dann reicht einmal tippen auf F1, und schon hat er wieder was gelernt.
Sagt jemand der gern so auf Performance achtet. Kopfzeilen sind schlecht. Ihre Verwendung erfordert a) mehr Speicher b) ist genauso inperformant, wie ein INTO, da die Daten im Speicher kopiert werden müssen.DeathAndPain hat geschrieben: ↑24.10.2024 18:07
Aber Kopfzeilen finde ich weit weniger schlimm als ihr Ruf. Sie erhöhen halt etwas die Lernkurve für ABAP-Neueinsteiger, das stimmt. Mein Eindruck ist aber, dass viele einfach zu dusslig sind, mit Kopfzeilen umzugehen und daher sagen, Kopfzeilen seien so schlecht.
Egal, so oder so sind sie Geschichte.
Ich versuche es mit einem Bild: Stell dir eine Tabelle vor, mit lauter Sätzen, die zueinander in Bezug stehen. Also z. B. eine EKKO, in der Rahmenverträge und Bestellungen zu finden sind. Dann ist mir eine Methode "finde_best_zu_rahmenvertr( )" lieber als ein READ, der nicht erklärt, was er da selektiert, sondern es nur technisch beschreibt.black_adept hat geschrieben: ↑Gestern 09:28Argh. Wenn ich, gerade bei dir, Ralf, "Iterator-ähnliches Konstrukt" lese, rollen sich mir die Zehnägel auf. Es ist mir unverständlich warum man sein Designpatternwissen überall unmotiviert einzusetzen auslebt. SAP bietet durch LOOP mit seinen diversen Ausprägungen bzw durch die SORTED-Tabellentypen doch implizit vorhandene Iteratoren, die wahrscheinlich >95% aller Fälle, wo man einen Iterator benötigt, abdecken. Das ist "programmieren an der Sprache ABAP vorbei".
Why 😱 ?
Einen Iterator mit einem simplen LOOP zu vergleichen ist auch ein wenig am Thema vorbei. Iteratoren bieten, was sonst nur über zusätzliche Codebefehle möglich ist, wie lines etc. Sicher hat SAP hier Codebasis geschaffen, die Iteratoren nicht zwangsläufig erforderlich macht. Das ist schon historisch begründet. Es wäre allerdings auch denkbar, das SAP mal die Codebasis schafft, bei einem Select direkt Objekte zu erzeugen. Was manchen Code viel besser machen würde.black_adept hat geschrieben: ↑Gestern 09:28Argh. Wenn ich, gerade bei dir, Ralf, "Iterator-ähnliches Konstrukt" lese, rollen sich mir die Zehnägel auf. Es ist mir unverständlich warum man sein Designpatternwissen überall unmotiviert einzusetzen auslebt. SAP bietet durch LOOP mit seinen diversen Ausprägungen bzw durch die SORTED-Tabellentypen doch implizit vorhandene Iteratoren, die wahrscheinlich >95% aller Fälle, wo man einen Iterator benötigt, abdecken. Das ist "programmieren an der Sprache ABAP vorbei".ralf.wenzel hat geschrieben: ↑Gestern 09:06Wichtige interne Tabellen verwalte ich über ein Iterator-ähnliches Konstrukt
Ralf
Why 😱 ?
Nein.
Warum? Hätte viele Vorteile.
Richtig. Aber es ist nicht denkbar, dass sie das macht. Es klappt ja nichtmal ein SWITCH in einer WHERE-Bedingung.
Ich finde das schon sehr berechtigt. Der Name benennt den eigentliche Zweck eines Iterartors: Es wird durch ihn quasi eine Wohlordnung auf einer Menge erzeugt, die es ermöglicht diese auf eine definierte Weise vollständig zu durchlaufen. Der Designpattern bringt evtl. noch ein paar Zusätze wie das Lines. Aber genau das bietet halt der Sprachumfang von fast allen Sprachen auch und ich würde einen Teufel tun und einen Iterator anlegen, wenn mir die Sprache ein kernelnahes Äquivalent anbietet.gtoXX hat geschrieben: ↑Gestern 10:36Einen Iterator mit einem simplen LOOP zu vergleichen ist auch ein wenig am Thema vorbei. Iteratoren bieten, was sonst nur über zusätzliche Codebefehle möglich ist, wie lines etc. Sicher hat SAP hier Codebasis geschaffen, die Iteratoren nicht zwangsläufig erforderlich macht. Das ist schon historisch begründet
Dafür sollte man ja die Zielvariable entsprechend benennen und kann bei komplexeren Dingen auch einfach mal einen Kommentar hinterlassen - gerade bei SELECTs bieten sich da Side-Comments an.ralf.wenzel hat geschrieben: ↑Gestern 12:16Ja, das mag sein, aber ich bleibe dabei: Ein sprechendes "get_...." ist in gewissen Fällen als ein technisches READ, wo man erst überlegen muss "was genau sucht der da aus der Tabelle raus?"....
Folgende Benutzer bedankten sich beim Autor tar für den Beitrag:
DeathAndPain
Nein, weil ein SELECT in eine DAO-Klasse hinter ein Interface gehört. Schon der Testbarkeit wegen.
GETTER auf Objekteigenschaften gelten bei uns als veraltet, weil man keine Objekteigenschaften abfragt, sondern Objektzustände.
Richtig, und deshalb braucht man den FREE-Befehl auch so selten. Meist lohnt er nicht, da die Routine eh bald zu Ende ist (oder die interne Tabelle noch benötigt wird).tar hat geschrieben:Ich meinte nicht, um lediglich die interne Tabelle zu leeren usw., sondern den gesamten Codeblock, in dem du eben eine interne Tabelle aufbaust, füllst, für irgendwas nutzt und leerst. Das könnte man immer in eine eigene Methode auslagern und dabei eben auf das Leeren verzichten, weil das durch das Verlassen der Methode ohnehin passiert. Je nach Komplexität/Umfang/Verständlichkeit der Methode wird man dies sowieso tun - gerade auch dann, wenn man 100%-ig sicherstellen will, dass im nächsten Durchlauf keine falsch gefüllten Variablen vorhanden sind.
Warum muss ich das machen? Ich habe ja deutlich verlinkt, dass die SAP selbst auch explizit auf meinem Standpunkt steht. Das ist mir an dieser Stelle gut genug. Wenn Du genau wissen möchtest, wieviel das ausmacht, steht es Dir frei, Dir ein entsprechendes Testprogrämmchen zu basteln und gerne auch das Ergebnis hier zum Besten zu geben. Mir ist aber nicht klar, weshalb ich das für Dich machen muss.tar hat geschrieben:Kannst du da vielleicht mal einen Benchmark mit jeweils 1000 Wiederholungen fahren mit diesen 3 Varianten?
- Loop mit CLEAR []
- Loop mit FREE
- Untermethode (in der die Tabelle erzeugt und gefüllt wird, aber ohne CLEAR und ohne FREE)
Da ist die Frage, was Du als "strikt" bezeichnest. Ich kenne den "strikten" Modus bei SELECT als den, bei dem man die Felder mit Komma aufzählen und alle Hostvariablen escapen muss. Und in diesem Modus darf durchaus INTO vor FROM stehen.gtoXX hat geschrieben:SAP schreibt im strikten Modus INTO immer als letzten Teil der Select Anweisung vor.
Diese Frage lässt sich leicht beantworten: Bei CLEAR geht aus dem Befehl nicht hervor, ob ein Feld oder eine interne Tabelle geleert wird (uneindeutig). REFRESH leert immer eine interne Tabelle und ist damit hundertprozentig eindeutig. Dabei spielt es keine Rolle, ob diese interne Tabelle eine Kopfzeile hat, und genau das macht REFRESH auch für moderne interne Tabellen tauglich.gtoXX hat geschrieben:CLEAR zu verwenden, wobei die gute Frage ist warum das uneindeutig sein soll, dass kann man eher über REFRESH sagen
Es sei denn, die Spaltennamen der internen Tabelle sind so gut gewählt, dass man das direkt aus dem READ ASSIGN erkennen kann.Ralf hat geschrieben:Ich versuche es mit einem Bild: Stell dir eine Tabelle vor, mit lauter Sätzen, die zueinander in Bezug stehen. Also z. B. eine EKKO, in der Rahmenverträge und Bestellungen zu finden sind. Dann ist mir eine Methode "finde_best_zu_rahmenvertr( )" lieber als ein READ, der nicht erklärt, was er da selektiert, sondern es nur technisch beschreibt.
Das ist auch völlig egal. Es handelt sich um ein Datenobjekt und das wird gelöscht. Dem Löschenden sollte egal sein, welcher Art das Objekt ist.DeathAndPain hat geschrieben: ↑Gestern 16:16Diese Frage lässt sich leicht beantworten: Bei CLEAR geht aus dem Befehl nicht hervor, ob ein Feld oder eine interne Tabelle geleert wird (uneindeutig).
Ich finde es lesbarer, das reicht mir als Vorteil.DeathAndPain hat geschrieben: ↑Gestern 16:16Das Problem bei Deiner Vorgehensweise besteht darin, dass Du die Abstraktion auf ein Niveau hochschraubst, auf dem sie keine Vorteile mehr bringt.
😂 Das ist doch nicht abstrakt! Ich schreibe oft genug generisches Coding, DAS ist abstrakt.
Nein, es ist nicht egal; er muss es wissen, sonst hat er den Code nicht verstanden. Klar lässt sich diese Information leicht beschaffen bzw. sollte bekannt sein, aber REFRESH ist halt eine Verbesserung der Anschaulichkeit, die nichts kostet. Anders ausgedrückt: Über den Vorteil von REFRESH mag man streiten können, aber Nachteile hat er nicht. Damit spricht nichts dagegen, ihn zu verwenden, um die Leerung interner Tabellen von der Leerung einfacher Datenfelder (incl. Strukturen) optisch abzugrenzen.ralf.wenzel hat geschrieben: ↑Gestern 16:33Das ist auch völlig egal. Es handelt sich um ein Datenobjekt und das wird gelöscht. Dem Löschenden sollte egal sein, welcher Art das Objekt ist.
Ja, damals wurde in der Schule noch Mathematik gemacht. Heutzutage lernen die Schüler selbst im Gymnasium nur noch, die p-q-Formel anzuwenden. Beweise stehen nicht mehr auf dem Lehrplan (und werden allenfalls mal von guten Mathelehrern eingestreut, aber von den Schülern nicht mehr verlangt).Ralf hat geschrieben:Wie sagte mein Mathelehrer, als wir mit quadratischen Gleichungen und p/q-Formeln und so angefangen haben? "Bildet euch nix drauf ein, das ist keine Mathematik, das ist die bürgerliche Form des Rechnens".
Das sehe ich anders, weil nämlich dann die Begriffe durcheinandergehen. Ein Objekt ist definiert als Instanz einer Klasse. Wenn man Begriffe derart mehrdeutig verwendet, entstehen Verwirrung und Missverständnisse.Ralf hat geschrieben:wobei es völlig legitim ist, eine interne Tabelle als Objekt zu betrachten.
Doch, du löschst ein Datenobjekt. Ob das ein Feld ist oder eine Struktur oder eine Tabelle, ist völlig unerheblich. Oder erklär mir doch mal, warum es nicht besonderen Löschbefehle für Strukturen gibt. Und da es die nicht gibt: Warum für Tabellen?
Nein, eben nicht. Du hast meinen Mathelehrer nicht verstanden. Schon damals war p/q-Formel keine Mathematik.DeathAndPain hat geschrieben: ↑Gestern 20:43Ja, damals wurde in der Schule noch Mathematik gemacht.Ralf hat geschrieben:Wie sagte mein Mathelehrer, als wir mit quadratischen Gleichungen und p/q-Formeln und so angefangen haben? "Bildet euch nix drauf ein, das ist keine Mathematik, das ist die bürgerliche Form des Rechnens".
Hä? Ich kann ein Auto, einen Beleg und sonstwas als Objekt betrachten, aber eine Tabelle nicht? Natürlich kann ich aus einer Tabelle ein Objekt machen, indem ich sie in einer Klasse verwalte.DeathAndPain hat geschrieben: ↑Gestern 20:43Das sehe ich anders, weil nämlich dann die Begriffe durcheinandergehen. Ein Objekt ist definiert als Instanz einer Klasse.Ralf hat geschrieben:wobei es völlig legitim ist, eine interne Tabelle als Objekt zu betrachten.