Umherspringende Methoden im quelltextbasierten Class Builder

Re: Umherspringende Methoden im quelltextbasierten Class Builder

Klar - da muss man drauf achten. Das gilt aber generell.

Ich habe schon FREE <..> gesehen, wo eigentlich UNASSIGN <..> hingehörte und <..> = lt_..[ .. ] wo eigentlich ASSIGN lt_..[ .. ] to <..> hingehörte.

Die Ausführung hat da nur durch Zufall fehlerfrei funktioniert. Sollte man deswegen aber FREE, UNASSIGN usw. nicht mehr nutzen dürfen, weil es mitunter falsch verwendet wird? 🙃

Re: Umherspringende Methoden im quelltextbasierten Class Builder

ralf.wenzel hat geschrieben: ↑

25.10.2024 10:45

Du hast die Ungarische Notation nicht verstanden. Die besagt, dass der Name den Typ des Objektes widerspiegelt. Der Zeilentyp von LT_EKKO ist EKKO, weshalb sie LT_EKKO heißen muss, wenn man der Ungarischen Notation folgt.

Wie kommst du eigentlich auf diese Behauptung?

Der Variablentyp ist: interne Tabelle, daher LT.

Die Quelle mag EKKO sein. Ich hab jedoch noch nirgends gelesen, dass die Quelle Teil der ungarischen Notation sein sollte. Die Quelle interessiert auch überhaupt nicht, da es mehrere Quellen geben kann und man die Zielstruktur grundsätzlich selbst definieren (oder zumindest einschränken) sollte (und sei es über Wahl der zu selektierenden Spalten). Man könnte da also im faulsten aller Fälle (SELECT *) höchstens die Zielstruktur noch entsprechend der Quelle(n) benennen (also hier: LTY_EKKO). Da spricht nichts dagegen. Wobei, wenn man wirklich so faul ist, dann kann man gleich SELECT * INTO @DATA nutzen und braucht sich um die Benamung der Zielstruktur überhaupt keine Gedanken zu machen.

Variablen jedoch (die die Zielstrukturen und generell eigene Strukturen nutzen), sollte man generell passend zu deren inhaltlichen Daten bezeichnen.

Re: Umherspringende Methoden im quelltextbasierten Class Builder

Es scheint, du verwechselst den grundsätzlichen Variablentyp (Referenz, Tabelle, Struktur, Wert) mit dem Datentyp (konkrete/s/r Interface;Klasse/Tabellentyp/Strukturtyp/Datenelement). Letzterer ist bei ABAP bzgl. der Variablenbezeichnungen grundsätzlich irrelevant und ich habe auch noch nirgends gelesen, dass man den einsetzen soll. Aber laut der allwissenden Müllhalde bist du da nicht der Erste, der Simonyi missverstanden hat.

Re: Umherspringende Methoden im quelltextbasierten Class Builder

Ich würde hier gerne nochmal einhaken bzgl. des FREE-Befehls. Nur diesen anstelle von CLEAR oder REFRESH zu verwenden, habe ich tatsächlich schon bei Leuten gesehen und war entsetzt.

Speicherbereiche zu belegen oder wieder freizugeben kostet Rechenleistung. Aus diesem Grund gibt ABAP diesen Speicher nicht sofort bei CLEAR oder REFRESH wieder frei, sondern hält ihn für neue Werte belegt (und gibt ihn ggf. bei Routinenende frei). Das ist richtig und sinnvoll so. Dementsprechend solltest Du Dir die vorletzte Zeile der Onlinedokumentation des FREE-Befehls mal anschauen:

https://help.sap.com/doc/abapdocu_750_i ... object.htm

Da hast Du schwarz auf weiß die Meinung der SAP dazu. Woraus sich auch ergibt, was davon zu halten ist, wenn jemand immer nur FREE schreibt. Das ist nämlich ein klares Zeichen dafür, dass er nicht verstanden hat, was FREE im Vergleich zu CLEAR bedeutet.

FREE kann man vor allem bei kurzfristigen temporären Tabellen gebrauchen. Im Organisationsmanagement stehe ich beispielsweise häufiger mal vor dem Problem, eine Personalnummerntabelle als TABLE OF PERSNO vorzuliegen zu haben. Für den FOR ALL ENTRIES IN eines SELECT auf die Tabelle HRP1001 brauche ich die Zeilen aber im Format SOBID (das mehr Stellen hat). Da mache ich dann sowas wie
Da der einzige Zweck der Tabelle temp_pernrn_as_sobid darin besteht, in diesem SELECT verwendet zu werden, brauche ich sie anschließend für den Rest des Programms definitiv nicht mehr. Also kann ich den von ihr belegten Speicher sofort nach dem SELECT freigeben. An dieser Stelle ist FREE richtig. Ansonsten aber werden interne Tabellen in aller Regel weiter benötigt (bis zum Ende der Routine). Sie einzeln vorher freizugeben, lohnt auch nicht. Nur wenn man sich sicher ist, dass man eine der verwendeten (lokalen) internen Tabellen definitiv nicht mehr braucht und das Ende der Routine noch fern ist, lohnt ein FREE.

Re: Umherspringende Methoden im quelltextbasierten Class Builder

Jeglicher Memory (auch der Initial-Memory) zu lt_sub_entries wird nach jedem Verlassen der Methode do_something_with_the_entry() automatisch freigeräumt (entspricht FREE)

Das würde ich vermuten. Auch wenn der Optimierer von ABAP zuweilen Erstaunliches tut.

und eine separate Untermethode könnte man im Grunde für jeden Anwendungsfall erstellen, wo du momentan explizit CLEAR benutzt, nicht wahr?

Diesen Gedanken verstehe ich nicht. Weshalb solltest Du jedesmal, wenn Du eine interne Tabelle leeren möchtest, stattdessen eine Untermethode rufen wollen?

Bedenke zudem, dass das Ganze nur relevant ist, wenn die interne Tabelle ausschließlich in der Untermethode genutzt wird. Ist sie Teil der Parameterschnittstelle (oder global), dann wird da gar nichts geleert (außer bei Wertübergabe, die bekanntlich etwas Performance kostet).

Jetzt überlege ich ferner, wie oft und wie arg tief verschachtelt die Logik - also der Stack - im SAP-Standard ist und kann nur schlussfolgern: es ist geradewegs umgekehrt der Ausnahmefall, gezielt CLEAR benutzen zu wollen/müssen.

Ich denke, wie genau die Stackverwaltung von ABAP programmiert ist, wissen wir alle nicht. Aber das Anfordern (Belegen) neuen Hauptspeichers sowie das Freigeben desselben erfordert einen gewissen Rechenaufwand. Bereits belegten Hauptspeicher zu nutzen, erspart dies. Daran lässt die SAP ja im oben verlinkten Hilfetext keinen Zweifel.

Bei klassischen Datenbanktabellen ist es übrigens seit jeher genauso. Deswegen hat man ja ein Problem, wenn man aus Versehen eine Tabelle mit Millionen von Müllzeilen füllt: Auch wenn Du diese anschließend wieder löschst, wird der dadurch belegte Platz im Tablespace der Datenbank mitnichten wieder freigegeben, denn auch die Datenbank geht davon aus, dass dieser Platz für zukünftige neue Tabelleneinträge recyclet werden kann und will keine Performance verschwenden. Willst Du den Platz wiederhaben, musst Du eine Reorganisation des Tablespaces anstoßen (und die dauert!). Zumindest habe ich es so in Erinnerung. Datenbanken entwickeln sich weiter und verhalten sich heutzutage womöglich anders als in den Zeiten, als ich sie administriert habe.

Selbst beim Dateisystem NTFS (von Windows) ist es so: Legst Du Millionen von Dateien an, wächst der von der Plattenverwaltung belegte Speicherplatz auf der Festplatte. Diesen bekommst Du nicht zurück, wenn Du die ganzen Dateien wieder löschst.

Re: Umherspringende Methoden im quelltextbasierten Class Builder

tar hat geschrieben: ↑

Gestern 01:37

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.

Wichtige interne Tabellen verwalte ich über ein Iterator-ähnliches Konstrukt (also in einer eigenen lokalen Klasse). Schon deshalb, weil aus einem READ dann ein Methodenaufruf wird, der sprechend ist. hole_formularsatz( ) oder so.


Ralf

Re: Umherspringende Methoden im quelltextbasierten Class Builder

ralf.wenzel hat geschrieben: ↑

20.10.2024 18:09

Ich stimme dir in Allem zu - bis auf eines:

DeathAndPain hat geschrieben: ↑

20.10.2024 18:02

INTO vor FROM. Nach meinem Dafürhalten war das einst bei SQL sogar so vorgeschrieben, jedenfalls bei Informix 4GL war diese Reihenfolge Pflicht. In ABAP schreibt aber sonst jeder zuerst FROM und danach erst INTO. ABAP akzeptiert beides.

Wenn ich etwas von A nach B lege, dann sage ich im normalen Sprachgebrauch IMMER erst, von wo und dann nach wo ich es lege. Sieht man ja schon am Anfang des Satzes.

Darum finde ich FROM vor INTO deutlich einfacher zu lesen.


Ralf

Nun ja die Frage stellt sich eher weniger. SAP schreibt im strikten Modus INTO immer als letzten Teil der Select Anweisung vor. Hat auch eine gewisse Logik Was->Woher->mit welchen Bedingungen->mit welchen Parametern->Wohin ?