Wann sollte man LIKE verwenden

[Quinn1225]

Man kann eine Typisierung mittels LIKE verwenden, um sein Coding robuster gegenüber zu machen. Oftmals braucht man lokale Hilfsvariablen. Zum Beispeil möchte man über eine Tabelle loopen, die als Parameter in eine Routine eingeht, und benötigt eine Workarea. In diesem Fall kann die Workarea relativ einfach deklarieren:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. FROM f USING itab TYP MYTAB.
2.   DATA wa LIKE LINE OF itab.
3.   DATA tmp_itab LIKE itab.
4.   LOOP AT ITAB INTO wa.
5.     ...
6.     APEND wa INTO tmp_itab.
7.   ENDLOOP.
8.  
9. ENDFORM.

GeSHi ©

Falls sich der Typ der Tabelle itab ändert, bleibt die Implementierung der Routine unbeeinflußt. Der Typ von wa und tmp_itab wird ja "relativ" zum Parameter itab bestimmt.

[Edin1867]

Moin.

Ist ja prinzipiell richtig, aber da der USING-Parameter Deiner FORM eh typisiert ist kannst Du die lokalen Felder ebenfalls typisieren. Der LIKE wäre nur dann sinnvoll, wenn der Parameter untypisiert oder nicht vollständig typisiert wäre. (Wenn ich allerdings untypisierte Parameter in einem Programm sehe könnte ich immer an der Wand hochgehen )

Generell sollte man LIKE nicht mehr verwenden, da es im Zusammenhang mit ABAP Objects verboten ist (oder mit einer der nächsten Versionen verboten wird).

Daher also besser:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. FORM f USING ut_itab TYPE itab_type.
2. DATA: ls_wa TYPE LINE OF itab_type
3.     , lt_itab TYPE itab_type.
4. ...
5.  

GeSHi ©

Gruß,
Haubi

[Willy1492]

Wenn ich allerdings untypisierte Parameter in einem Programm sehe könnte ich immer an der Wand hochgehen .

Die Typisierung von FORM-Schnittstellen wurde zu 3.0 eingeführt, wenn ich mich richtig erinnere.
Zu 3.0 gab es in der SE38 auch noch einen Menüpunkt Hilfsmittel->Typisierung, der das Programm RSPARM30 gestartet hat.
Das Programm untersuchte im angegebenen Rahmenprogramm alle FORMs mit untypisierten Parametern, suchte nach passenden PERFORM-Anweisungen, analysierte die Herkunft und Typisierung der Aktualparameter und generierte Vorschläge f'ür die Typisierung.
In der Liste konnte man dann per Checkbox angeben, welche Typisierung das Programm vornehmen sollte. Beim Sichern hat das Programm automatisch die FORM-Schnittstellen angepaßt.
Aber kaum ein Kunde wußte von dieser Funktion.
Zu 4.0 wollte ich das Programm noch mal verwenden.

Der Menüpunkt war verschwunden, aber das Programm existierte noch.
Im Programm habe ich dann 2 Fehler entdeckt:
1. die Prüfung, ob es externe PERFORMs gibt, war fehlerhaft.
2. Wenn das Programm auf Aktualparameter gestoßen ist, die per STATICS definiert wurden, kam es zum Fehler.
Die falsche Prüfung auf externe Performs hat SAP in einem Patch für 3.1I behoben, das Problem mit STATICS-Anweisungen nicht.
Also habe ich RSPARM30 nach ZSPARM30 kopiert, die Includes, die verändert werden mußten, ebenfalls kopiert und in meinem Rahmenprogramm ersetzt, den Rest übernommen.
Mit irgendeinem späteren Release wurden dann alle Restbestände von RSPARM30 entsorgt, so daß auch mein ZSPARM30 ohne die Includes nicht mehr funktionierte.
Und alles from scratch noch mal zu programmieren war mir dann doch zu viel Aufwand.

Generell sollte man LIKE nicht mehr verwenden, da es im Zusammenhang mit ABAP Objects verboten ist (oder mit einer der nächsten Versionen verboten wird).

Daher also besser:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. FORM f USING ut_itab TYPE itab_type.
2. DATA: ls_wa TYPE LINE OF itab_type
3.     , lt_itab TYPE itab_type.
4. ...
5.  

GeSHi ©

Auch ohne ABAP Objects kann es schon zu 4.6 zu Problemen kommen, wenn man LIKE verwendet.
Ich hab das mal beim Upgrade von 4.6B auc 4.6C gesehen.
In Kundenprogrammen, in denen z.B.

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. DATA: feld LIKE ddicstruct-feld.

GeSHi ©

vorkam, gab es einen Syntaxfehler, nachdem SAP an die DDIC-Struktur weitere Komponenten angehängt hatte, so daß die Struktur plötzlich keine flache Struktur mehr war.
(Das verwendete Feld selbst war aber nach wie vor CHAR.)

Ist jemand "mutig" und definiert eine APPEND-Struktur für SYST, in der dann ein Tabellentyp als Komponente verwendet wird?
Wie oft kommt wohl DATA: rc LIKE SYST-SUBRC und ähnliches in Programmen vor?
Und ob der Fehler auch auf LIKE SY-SUBRC durchschlägt?
Neugierig bin ich ja. Noch möchte ich mir mein WAS Linux TestDrive aber nicht kaputtmachen.
Evtl. zerlege ich aber demnächst das MiniWAS. Dann berichte ich mal.

Frank

[Quinn1225]

@Haubi: Ich dachte nicht an eine Änderung von itab_type, sondern daran, dass man den Typ des Parameters von itab_type in einen anderen Typ ändert - z.B. itab_type2. In diesem Fall müsste man bei Deiner Lösung alle Typisierungen ändern.
Man kann sich mit LIKE nicht auf generische Variablen beziehen. Jedenfalls gilt dies für lokale Variablen. Variablen (keine Referenzparameter, Feldsymbole etc.) müssen immer einen konkreten - also nicht generischen - Typ besitzen, da ABAP ja den Speicherplatz reservieren muß.

@Haubi, Frank: Es ist keinesfallss so, dass LIKE in ABAP Objects verboten ist. Warum auch, es ist ein sehr sinvolles Feature. Früher war es jedoch möglich sich auf DDIC-Typen sowohl mit LIKE als auch mit TYPE zu beziehen. Dies widerspricht kedoch der allgemeinen Auffassung, dass man sich mit TYPE auf Typen und mit LIKE auf Variablen bezieht. Da man nicht jeden LIKE-Bezug auf einen DDIC-Typ im Nachhinein verbieten konnte, hat man dies nur für "tiefe" DDIC-Typen verboten. Diese waren zu 4.6 noch sehr neu, so dass ein Verbot noch möglich war. Im Kontext von ABAP Objets jedoch sind LIKE-Bezüge auf DDIC-Typen generell verboten.

[Ilja583]

Auszug aus der F1-Hilfe zum TYPE-Befehl (Zusatz 2 ... like F )

Hinweis
In vielen Fällen ist es sehr empfehlenswert, diesen Zusatz zu verwenden. Typänderungen von Feldern, auf die man sich bezieht, bekommt das Programm automatisch mit. Außerdem werden ggf. keine unnötigen und evtl. auch ungewollten Konvertierungen durchgeführt.

bzw. fast genauso der Hinweistext in der F1-Hilfe zum DATA-Befehl:

Wann immer sinnvoll, sollte man diesen Zusatz verwenden. Typänderungen von Feldern, auf die man sich bezieht, werden vom ABAP-Laufzeitsystem automatisch berücksichtigt. Außerdem werden keine unnötigen und evtl. auch ungewollten Konvertierungen durchgeführt.

wobei hier natürlich zu fragen ist, was genau mit "Wann immer sinnvoll" wohl gemeint ist.


@Frank:
Dein Beispiel mit dem Problem einer LIKE-Referenzierung nachdem SAP ein Standardfeld geändert hat ist wohl berechtigt, aber meinst du nicht, dass genau dasselbe Problem auftauchen kann, wenn SAP (oder man selber) in einem Tabellenfeld das Datenelement ändert, z.B. von integer nach numc oder die Länge eines C-Feldes ein wenig erweitert?

Und auch wenn ich mich hier zum Anfänger erkläre: Ich krieg es einfach nicht hin das im folgenden Coding liegende LIKE durch ein äquivalentes TYPE zu ersetzen.

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. REPORT  zzztest .
2.  
3. TYPES: BEGIN OF type1,
4.          x1,
5.          x2,
6.          x3,
7.        END OF type1.
8.  
9. DATA: dt TYPE STANDARD TABLE OF type1.
10.  
11.  
12. TYPES: BEGIN OF t2,
13.          t1 LIKE dt,
14.          t2,
15.          t3,
16.        END OF t2.
17.  

GeSHi ©

[Quinn1225]

Das Problem in deinem Beispiel ist, dass Typangaben bei DATA und TYPES leicht unterschiedlich interpretiert werden.
Bei Data dürfen keine generischen Typen angegeben werden. Fehlen Angaben (wie beispielsweise eine Länge oder ein Schlüssel, so werden Defalutwerte ergänzt).
Bei TYPES ist dies nicht der Fall. Fehlen Angaben, so handelt es sich um einen generischen (da unvollständigen Typ). Dazu ein kleines Beispiel:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. DATA x TYPE C

GeSHi ©

legt eine Varable vom Typ C(1) an.

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. TYPE tx TYPE C

GeSHi ©

legt einen Typ C mit unspezifierter Länge an.

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. TYPE tx TYPE C(1)

GeSHi ©

legt einen Typ an, der C(1) entspricht.
Um auf Dein Beispiel zurückzukommen:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. DATA: dt TYPE STANDARD TABLE OF type1.

GeSHi ©

erzeugt eine interne Standardtabelle mit Defaultkey.
Innerhalb einer TYPES-Anweisung wird jedoch die fehlende Angabe zum Schlüssel nicht mit WITH DEFAULT KEY ergänzt. Es handelt sich also um einen generischen Typ, da der Schlüssel unspezifiert bleibt. Genrische Typen sind jedoch für Strukturkomponenten nicht gestattet. Du solltest Dein Beispiel also wie folgt formulieren:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. TYPES: BEGIN OF t2,
2.          t1 TYPE STANDARD TABLE OF type1 WITH DEFAULT KEY,
3.          t2,
4.          t3,
5. END OF t2.

GeSHi ©

[Ilja583]

Soso,

endlich mal jemand der mich erleuchtet.

Die Info ist so interessant, dass mich eigentlich noch mehr interessiert, wo das denn in der Doku steht - normalerweise frage ich solche Fragen nämlich nicht sondern suche die Antwort selber, aber da hatte ich nix gefunden.