Code: Alles auswählen.
DATA: BEGIN OF I_BESTLMENG OCCURS 1000,
MATNR like ekpo-matnr ,
INDEX(6) type c ,
MENGE(24) type c,
NUMBER(4) type C,
END OF I_BESTLMENG.
*
TYPES:
BEGIN OF T_LINE2,
EBELN like ekpo-ebeln,
STRICH1 type C,
AEDAT(10) type C,
STRICH2 type C,
EINDT(10) type C,
STRICH3 type C,
MENGE(8) type C,
STRICH4 type C,
MATNR(25) type C,
END OF T_LINE2,
ITAB2 type T_LINE2 OCCURS 1000.
Ich sehe anderes mit Haus.Romaniac hat geschrieben:TYPES ist wie die Definition Deines Hauses, der Plan des Architekten. Mit diesem Plan kannst Du mehrere gleiche Häuser bauen.
DATA ist dann ein gebautes Haus, sprich Deine Tabelle ist im Speicher angelegt.
Amen.DeathAndPain hat geschrieben:Um Himmels willen, lasst doch bitte diese blöden Vergleiche, die verwirren doch nur, anstatt zu erhellen. Das erinnert ja gewaltig an die Standarderklärungen von Objekten in objektorientierter Programmierung (Auto und Flugzeug als Klasse, Gefährt als Superklasse usw.), die auch alle einleuchtend sind, und trotzdem weiß man hierher nicht, was man als Programmierer nun mit solch Objekten anfangen soll, denn man will ja Programme und Funktionalitäten für Benutzer implementieren und keine Autos oder Flugzeuge. Am Ende definiert man dann eine Klasse, um objektorientiert zu sein, und schreibt den eigentlichen Programmcode in den Constructor (von dem man dann bei Programmstart eine Instanz erzeugt und das war's).
Ich halte es da ganz einfach:DeathAndPain hat geschrieben:Und wenn ich schon beim OO-Bashing bin: Analog zur vom Threadersteller gestellten Frage würde mich der genaue Unterschied zwischen TYPE und LIKE interessieren. Einstmals war er klar, aber mit der Einführung von OO muss man plötzlich an vielen Stellen TYPE schreiben, wo vorher LIKE angesagt war, so dass es angesichts der weiterhin vorhandenen Zulässigkeit der alten Syntax ein übles Kuddelmuddel gibt.
Naja - ganz so deprecated oder sinnlos wie adt das gerade darstellt ist das ja gar nicht und das ist tatsächlich eine der Besonderheiten, die ABAP von den meisten anderen Sprachen abhebt.DeathAndPain hat geschrieben:Und wenn ich schon beim OO-Bashing bin: Analog zur vom Threadersteller gestellten Frage würde mich der genaue Unterschied zwischen TYPE und LIKE interessieren. Einstmals war er klar, aber mit der Einführung von OO muss man plötzlich an vielen Stellen TYPE schreiben, wo vorher LIKE angesagt war, so dass es angesichts der weiterhin vorhandenen Zulässigkeit der alten Syntax ein übles Kuddelmuddel gibt.
Code: Alles auswählen.
CREATE DATA lr_ref LIKE STANDARD TABLE of i_input WITH NON-UNIQUE DEFAULT KEY
Das sehe ich etwas anders. Beispiel:Mit dem LIKE verhält sich das etwas ander. Das ist so eine ABAP Besonderheit. Muss wohl ein ganz fauler Programmierer gewesen sein, der nicht die Zeit und Muse hatte, einen Datentyp zu definieren und lieber mit den Variablennamen herumhantieren wollte. LIKE definiert ebenfalls eine Variable mit Bezug auf den Datentyp einer anderen Variable. Man kann also nur durch Änderung einer Variable viele weitere (Schnitt-)Stellen mitändern, was aber eigentlich auch mit einem sauberen Typ-Konzept möglich gewesen wäre.
Code: Alles auswählen.
DATA: t TYPE STANDARD TABLE OF c,
l_t LIKE LINE OF t.
Auch das haut nicht konsequent bis zum Ende hin. Versuch mal, den TABLES-Parameter eines Funktionsbausteins mit "TYPE SOLISTI1" zu definieren. Da bekommst Du eine Fehlermeldung. Nimmst Du aber "LIKE SOLISTI1", dann geht es, auch wenn SAP Dir dann eine Warnmeldung um die Ohren schlägt, dass LIKE veraltet sei. Hier beziehst Du Dich also bei einer Variablendefinition auf das DDIC, und dennoch geht nur LIKE und nicht TYPE.Genaugenommen müsste man sich auf eine DDIC-Struktur mittels "TYPE" beziehen, da durch das DDIC ja nur eine Strukturdefinition und keine Variable dieses Namens bereit gestellt wird - aber ich schätze, dass die (fast) obsolete TABLES-Anweisung, der Grund war warum man damals beides erlaubt hat.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
black_adept
Dank des LIKE sind meines Erachtens beim Late Binding mit ANY auch keine besseren Lösungen möglich. Man kann ja dadurch z.B. trotzdem nicht "statisch" zur Designzeit auf einzelne Felder einer Struktur zugreifen ohne sich mit ASSIGN COMPONENT eine "dynamische" Eselsbrücke zu bauen. Einzige wirkliche Erleichterung gibt es meines Erachtens nur bei Feldsymbolen, Workareas und Zeilenreferenzen zu Tabellen mit LIKE LINE OF. Aber auch das kann man mit TYPE LINE OF auch anders schreiben wenn man sein Typkonzept sauber aufgezogen hat (zu jedem Tabellentyp einen eigenen Zeilentyp usw.).black_adept hat geschrieben:Nichtsdestotrotz ermöglicht die LIKE Definition Sachen, die auch ein strenges Typkonzept nicht ermöglichen würden. Insbesondere ermöglicht es das late-binding von Variablen.
Beispiel - mit einem Übergabeparameter i_input vom Typ ANY (z.B. zum Erstellen von Tabellen mit frei definiertem Zeilentyp ohne die hiergegen etwas umständliche RTTI-Methodik )
Versuchs mal mit TYPE SRM_T_SOLISTI1 oder ähnlichen. TABLES braucht nämlich (wie der Name auch irgendwie vermuten lässt) einen Tabellentyp und keine Struktur.DeathAndPain hat geschrieben:Auch das haut nicht konsequent bis zum Ende hin. Versuch mal, den TABLES-Parameter eines Funktionsbausteins mit "TYPE SOLISTI1" zu definieren. Da bekommst Du eine Fehlermeldung. Nimmst Du aber "LIKE SOLISTI1", dann geht es, auch wenn SAP Dir dann eine Warnmeldung um die Ohren schlägt, dass LIKE veraltet sei. Hier beziehst Du Dich also bei einer Variablendefinition auf das DDIC, und dennoch geht nur LIKE und nicht TYPE.Genaugenommen müsste man sich auf eine DDIC-Struktur mittels "TYPE" beziehen, da durch das DDIC ja nur eine Strukturdefinition und keine Variable dieses Namens bereit gestellt wird - aber ich schätze, dass die (fast) obsolete TABLES-Anweisung, der Grund war warum man damals beides erlaubt hat.
Bei "das Leben erleichtern" geb ich dir natürlich recht. Aber man muss da schon sehr genau abwägen (Erfahrung!) wann man wirklich mit CHECK, EXIT usw. arbeiten sollte. Was die Lesbarkeit betrifft: Ein unbedeachtes CHECK irgendwo mittendrinn in einem über 1000 Zeilen Legacy-Code kann man leichter übersehen als ein IF-Konstrukt mit Einrückungen.DeathAndPain hat geschrieben:Und was das "ganz fauler Programmierer" angeht, so bin ich für alles, was Programmierern das Leben erleichtert, ohne den Code schlechter lesbar zu machen. In den allermeisten Fällen ist kürzerer Code auch besser lesbar. Deswegen rege ich mich auch darüber auf, dass Kopfzeilen deprecated sind. Ich finde Code, der mit Kopfzeilen arbeitet, wunderbar lesbar und verständlich. Arbeitet man mit separaten "Arbeitszeilen", dann wird der Code wesentlich länger und damit unübersichtlicher, ohne tatsächlich Mehrwert an Information zu bieten (z.B. LOOP AT mytable INTO ls_mytable statt einfach LOOP AT mytable). Genauso bin ich auch ein Fan des CHECK-Befehls, der leider auch weitgehend deprecated ist, wenngleich die SAP ihn bislang meines Wissens noch nirgends verboten hat, und ich mag auch die neuen Konstrukte NMIN( ) und LINES( ) sowie den gleichfalls relativ neuen &&-Operator (Das umständliche CONCATENATE war mir schon immer ein Dorn im Auge).
Da hast Du sicherlich recht. Aber ich meine mich zu erinnern, dass es unter Release 3.x noch überhaupt keine Tabellentypen gegeben hat. Auf jeden Fall gab es keine geschachtelten Tabellen. Von daher war das damals schon inkonsequent, da mit LIKE zu arbeiten, besser wäre sicherlich das Schlüsselwort STRUCTURE gewesen, das diesen Umstand veranschaulicht hätte.Versuchs mal mit TYPE SRM_T_SOLISTI1 oder ähnlichen. TABLES braucht nämlich (wie der Name auch irgendwie vermuten lässt) einen Tabellentyp und keine Struktur.
Mitdenken muss man dabei auf jeden Fall, denn CHECK ist ein sehr flexibler Befehl, den man in seinem Kontext richtig interpretieren muss. Normalerweise ist das aber kein Problem, und ich pflege nach CHECK auch eine Leerzeile zu machen.Bei "das Leben erleichtern" geb ich dir natürlich recht. Aber man muss da schon sehr genau abwägen (Erfahrung!) wann man wirklich mit CHECK, EXIT usw. arbeiten sollte.
Ich meinte eigentlich das früher zu hauf verwendete TABLES-Statement in Programmen als alternative/obsolete Deklaration einer Variablen und nicht das TABLES-Statement diverser Schnittstellen.DeathAndPain hat geschrieben:[...]
Auch das haut nicht konsequent bis zum Ende hin. Versuch mal, den TABLES-Parameter eines Funktionsbausteins mit "TYPE SOLISTI1" zu definieren.
...