Code: Alles auswählen.
CLASS lcl_alv_grid DEFINITION DEFERRED.
Eine Schwäche von ABAP OO, nicht von OO generell.DeathAndPain hat geschrieben: ↑08.05.2023 20:42Ja, das ist eine Schwäche von OO, dass es relevant ist, wo im Code die Klassen- und Methodendefinitionen stehen.
Wenn man Java als Vergleich nimmt, sieht man wie es besser lösbar gewesen wäre. ABAP hat sich da scheinbar von C++ mit seinen Header-Files "inspirieren" lassen.DeathAndPain hat geschrieben: ↑08.05.2023 20:42Völlig sinnlose Einschränkung; schon bei den alten Formroutinen war das völlig egal, aber gehört halt zum bürokratischen Wasserkopf von ABAP OO.
Es war auch bei den Form-Routinen nicht egal. Der ABAP Compiler ist wie viele Compiler zeilen-orientiert. Die Deklaration muss also immer vor der Verwendung kommen.DeathAndPain hat geschrieben: ↑08.05.2023 20:42Ja, das ist eine Schwäche von OO, dass es relevant ist, wo im Code die Klassen- und Methodendefinitionen stehen. Völlig sinnlose Einschränkung; schon bei den alten Formroutinen war das völlig egal, aber gehört halt zum bürokratischen Wasserkopf von ABAP OO.
Ich bin gespannt wie Du in Java eine Routine aufrufst, die du nicht vorher per Bibliothek gelinkt hast. Den Laufzeitfehler hast du garantiert gewonnen. Im Gegenteil ABAP arbeitet da exakt wie Java.a-dead-trousers hat geschrieben: ↑08.05.2023 22:55Eine Schwäche von ABAP OO, nicht von OO generell.DeathAndPain hat geschrieben: ↑08.05.2023 20:42Ja, das ist eine Schwäche von OO, dass es relevant ist, wo im Code die Klassen- und Methodendefinitionen stehen.Wenn man Java als Vergleich nimmt, sieht man wie es besser lösbar gewesen wäre. ABAP hat sich da scheinbar von C++ mit seinen Header-Files "inspirieren" lassen.DeathAndPain hat geschrieben: ↑08.05.2023 20:42Völlig sinnlose Einschränkung; schon bei den alten Formroutinen war das völlig egal, aber gehört halt zum bürokratischen Wasserkopf von ABAP OO.
Sorry, du hast natürlich recht. Ich bezog mich auf die DECLARATION/IMPLEMENTATION Trennung und damit darauf, dass immer zuerst die Deklaration kommen muss bevor man etwas aufrufen kann. Auch wenn ich mich im selben Report bewege. In Java ist es hingegen egal in welcher Reihenfolge in einer Datei die Klassen definiert sind (wenn man sie nicht in mehreren Dateien getrennt definiert). Bei Bibliotheken oder Objekten aus anderen Dateien muss natürlich zuerst die IMPORT-Anweisung stehen.gtoXX hat geschrieben: ↑08.05.2023 23:29Ich bin gespannt wie Du in Java eine Routine aufrufst, die du nicht vorher per Bibliothek gelinkt hast. Den Laufzeitfehler hast du garantiert gewonnen. Im Gegenteil ABAP arbeitet da exakt wie Java.a-dead-trousers hat geschrieben: ↑08.05.2023 22:55Eine Schwäche von ABAP OO, nicht von OO generell.DeathAndPain hat geschrieben: ↑08.05.2023 20:42Ja, das ist eine Schwäche von OO, dass es relevant ist, wo im Code die Klassen- und Methodendefinitionen stehen.Wenn man Java als Vergleich nimmt, sieht man wie es besser lösbar gewesen wäre. ABAP hat sich da scheinbar von C++ mit seinen Header-Files "inspirieren" lassen.DeathAndPain hat geschrieben: ↑08.05.2023 20:42Völlig sinnlose Einschränkung; schon bei den alten Formroutinen war das völlig egal, aber gehört halt zum bürokratischen Wasserkopf von ABAP OO.
Das halte ich für ein Gerücht. Seit ein paar Monaten bin ich auf Methoden umgestiegen, weil die zwar aufwendiger anzulegen, aber unendlich viel übersichtlicher aufzurufen sind, aber in all meinen alten Programmen lautet die Reihenfolge Variablendeklaration, (ggf.) Selektionsbild, START-OF-SELECTION-Block mit den PERFORMs der höchsten Aufrufebene und dahinter dann die Formroutinen. Bedeutet, dass die Formroutinen immer hinter der Stelle stehen, von der sie aufgerufen werden. Versuch das mal mit einer Methode, wenn nicht zumindest deren DEFINITION-Block vor der Aufrufstelle steht. Da reicht noch nicht mal die DEFINITION DEFERRED-Krücke; die macht nur die Typdefinitionen der Klasse zugänglich, soweit ich mich erinnere.gtoXX hat geschrieben: ↑08.05.2023 23:27Es war auch bei den Form-Routinen nicht egal. Der ABAP Compiler ist wie viele Compiler zeilen-orientiert. Die Deklaration muss also immer vor der Verwendung kommen.DeathAndPain hat geschrieben: ↑08.05.2023 20:42Ja, das ist eine Schwäche von OO, dass es relevant ist, wo im Code die Klassen- und Methodendefinitionen stehen. Völlig sinnlose Einschränkung; schon bei den alten Formroutinen war das völlig egal, aber gehört halt zum bürokratischen Wasserkopf von ABAP OO.
Dann müsste ja das INCLUDE programmname_TOP im Hauptprogramm zu einem Compilerfehler führen, wenn der das TOP-Include eigenständig vorher schon einbinden würde.Viele wissen nicht mal , das in ein TOP Include die Report Anweisung gehört. Denn das ist eine Besonderheit bei ABAP. Es wird zuerst nach einem Include mit _TOP am Ende gesucht. Dies wird vor dem Ereignis LOAD-OF-PROGRAM immer zuerst gelesen. Egal wo es steht. Danach werden die Includes in der Reihenfolge abgearbeitet wie sie im Code stehen.
Das TOP-Include enthält die ganzen Typ- und globalen Felddefinitionen. Welches Include sollte irgendwer früher als das aufrufen wollen?Die meisten folgen der Empfehlung von SAP, weswegen es kaum auffällt. Wenn du die Inklude Reihenfolge mal änderst erfreut dich der Compiler mit zahlreichen Fehlern.