corresponding - mapping - switch
Beitrag
von DeathAndPain (Top Expert / 1939 / 257 /
412
)
»
Bis mir gibt es diesen Zusatz nicht (auch nicht in der F1-Hilfe). Dein Link verweist auf die Cloud-Doku. Wird vermutlich ein sehr neues Release erfordern.
Unhübsch finde ich den Zusatz aber nicht. Das wird er in meinen Augen nur durch Deine Formatierung und dadurch, dass Du ohne Not COND statt SWITCH verwendest. SWITCH ist spezieller und kann COND daher nicht immer ersetzen, aber in den Fällen, in denen es geht, ist SWITCH eigentlich immer die besser lesbare Wahl (womöglich auch performanter, denn CASE soll ja auch performanter sein als IF, aber das habe ich nicht gemessen und sollte auch nicht relevant sein).
Ich hätte es so geschrieben:
Und das finde ich sehr schön lesbar. Auch wenn man über die Stellung des "default" zunächst stolpert, aber das wird daran liegen, dass wir den Zusatz aus Releasegründen nicht gewohnt sind.
Unhübsch finde ich den Zusatz aber nicht. Das wird er in meinen Augen nur durch Deine Formatierung und dadurch, dass Du ohne Not COND statt SWITCH verwendest. SWITCH ist spezieller und kann COND daher nicht immer ersetzen, aber in den Fällen, in denen es geht, ist SWITCH eigentlich immer die besser lesbare Wahl (womöglich auch performanter, denn CASE soll ja auch performanter sein als IF, aber das habe ich nicht gemessen und sollte auch nicht relevant sein).
Ich hätte es so geschrieben:
Code: Alles auswählen.
zielstruc = corresponding #( quellstruc mapping field1 = default switch #( lv_field1 when 'B' then 'B'
else 'P' ).
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Da fehlt aber eine Klammer, was bei deiner Formatierung halt nicht, bei meiner schlagartig auffällt 😉
Ich finde das Konstrukt aber an sich schlecht und verwende CORRESPONDING außerhalb von SELECTs recht selten. Ich meine, mich auch zu erinnern, dass es - zumindest vor einigen Jahren - auch explizit ausgeschlossene Felder, die vorher gefüllt waren, geleert oder überklatscht hat. War recht seltsam.
Ich finde das Konstrukt aber an sich schlecht und verwende CORRESPONDING außerhalb von SELECTs recht selten. Ich meine, mich auch zu erinnern, dass es - zumindest vor einigen Jahren - auch explizit ausgeschlossene Felder, die vorher gefüllt waren, geleert oder überklatscht hat. War recht seltsam.
Beitrag
von DeathAndPain (Top Expert / 1939 / 257 /
412
)
»
Das wäre mir im praktischen Betrieb auch schnell aufgefallen, weil es mir der Editor beim Compilieren nämlich um die Ohren gehauen hätte. 😁 Danach bleibt dann nur noch die bessere Lesbarkeit des Konstrukts für nach mir kommende Menschen (oder mich selber in einem halben Jahr).
Ich mag CORRESPONDING sehr gerne. Ich treffe immer wieder auf Fälle, in denen es sich plötzlich anbietet. Insbesondere das FILTER-Konstrukt ist ohne gleichzeitigen Einsatz von CORRESPONDING kaum zu gebrauchen, denn man will ja in aller Regel nicht in derselben Routine mit mehreren identisch typisierten internen Tabellen hantieren. Nehmen wir beispielsweise an, dass Du eine interne Tabelle hast, in der Du die ganzen Materialien mit dem zugehörigen Lagerort gepuffert hast (mit Schlüssel auf den Lagerort) und willst jetzt alle Materialien, die an einem bestimmten Lagerort liegen, in Deine ALV-Tabelle übernehmen, die Material uns zugehörigen Text enthält, dann könntest Du das z.B. so bewerkstelligen:Ich finde das Konstrukt aber an sich schlecht und verwende CORRESPONDING außerhalb von SELECTs recht selten.
Code: Alles auswählen.
TYPES: BEGIN OF puffer_lagerort_zeile,
lgort type lgort,
matnr type matnr,
END OF puffer_lagerort_zeile,
BEGIN OF alv_ausgabetabelle_zeile,
matnr type matnr,
maktx type maktx,
END OF alv_ausgabetabelle_zeile.
DATA: puffer_lagerort TYPE SORTED TABLE OF puffer_lagerort_zeile WITH NON-UNIQUE KEY lgort,
alv_ausgabetabelle TYPE STANDARD TABLE OF alv_ausgabetabelle_zeile WITH EMPTY KEY.
puffer_lagerort = alle_lagerorte_puffern( ). " enthält einfach einen passenden SELECT
* Zeilen für alle Materialnummern, die am Lagerort ABCD liegen, in der Ausgabetabelle anlegen
alv_ausgabetabelle[] = CORRESPONDING #( FILTER #( puffer_lagerort WHERE lgort = 'ABCD' ) ). " überträgt nur die Spalte MATNR, denn nur die gibt es in beiden Tabellen
ergaenze_textspalte( CHANGING alv_ausgabetabelle ). " Liest zu jeder Materialnummer den zugehörigen Text in die Spalte MAKTX
gib_alv_aus( alv_ausgabetabelle ).Die Kürze hat eine gewisse Eleganz, verbirgt aber, was nun genau übernommen wurde - und deswegen mag ich CORRESPONDING nicht, weil man da immer mehrfach nachprüfen und hin- und herspringen muss.
Daher würde ich dies (abgesehen vom offensichtlichen INNER JOIN als Lösung, aber es geht ja um die Logik des Filterns und Anreicherns) so umsetzen:
Deklaration, Filtern, Füllen und Anreichern in einem Aufruf. Das hat auch so einiges mehr an Potential, erweitert zu werden und dabei verständlich zu bleiben. Vor allem sieht man direkt im Code und ohne lästiges Hin- und Hergespringe (im Gegensatz zum CORRESPONDING), was denn nun eigentlich wie gefüllt wird.
Nebenbemerkung:
Von CHANGING-Parametern rate ich ernsthaft ab (nur nutzen, wenn es wirklich gar nicht anders geht). Stattdessen ist IMPORTING und RETURNING vorzuziehen. Siehe auch diesen Beitrag.
Daher würde ich dies (abgesehen vom offensichtlichen INNER JOIN als Lösung, aber es geht ja um die Logik des Filterns und Anreicherns) so umsetzen:
Code: Alles auswählen.
data(lt_alv_data) = value ltty_alv_data(
for line in lt_lagerorte where (
id = 'ABCD'
" ... weitere where bedingungen ...
) (
materialbeschreibung = read_material( line-materialnr )-beschreibung
materialnr = line-materialnr
" ... fülle direkt weitere spalten ...
)
).Nebenbemerkung:
Von CHANGING-Parametern rate ich ernsthaft ab (nur nutzen, wenn es wirklich gar nicht anders geht). Stattdessen ist IMPORTING und RETURNING vorzuziehen. Siehe auch diesen Beitrag.
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Im verlinkten Beitrag steht schon richtig: Wenn eine Methode eine Variable ändert, nimmt man CHANGING, schon um genau das anzuzeigen. RETURNING hat den "Fehler" dass man nur einen Wert übergeben kann.
Richtig schräg (um nicht das andere Wort mit sch.... zu verwenden) finde ich Methoden (gibts auch von der SAP), die EXPORTING *und* RETURNING-Parameter haben.
Ralf
Richtig schräg (um nicht das andere Wort mit sch.... zu verwenden) finde ich Methoden (gibts auch von der SAP), die EXPORTING *und* RETURNING-Parameter haben.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 1939 / 257 /
412
)
»
Genau so ist es. Da haben sich ja auch einige Leute in dem Beitrag dafür ausgesprochen. Die Argumentation, die tm987456 dort dagegen angeführt hat, finde ich sehr schräg, weil er im Prinzip argumentiert, dass er mit RETURNING mehr Möglichkeiten habe als mit CHANGING, ungeachtet des Umstands, dass man diese Möglichkeiten gar nicht braucht, wenn man CHANGING schreibt.Ralf hat geschrieben:Im verlinkten Beitrag steht schon richtig: Wenn eine Methode eine Variable ändert, nimmt man CHANGING, schon um genau das anzuzeigen.
Anders formuliert: Es geht ja nicht darum sich festzulegen, dass man fortan nur noch CHANGING oder nur noch RETURNING verwenden wird. Wenn man das müsste, dann wäre die flexiblere Variante in der Tat vorzuziehen. Aber solange man einfach ein Feld ändern möchte und für eine über den konkreten Anwendungsfall hinaus gehende Flexibilität gar keine Verwendung hat, finde ich es abwegig, sich auf eine Syntax festzulegen.
Ein Code sollte möglichst sprechend geschrieben sein, dann ist er gut verständlich. CHANGING ist an dieser Stelle vorbildlich. Problematischer wäre es schon, stattdessen (beim Aufruf) IMPORTING zu verwenden und den Umstand zu nutzen, dass EXPORTING-Parameter von Methoden sich letztlich auch wie CHANGING-Parameter verhalten, da sie als Referenz übergeben werden (sofern nicht ausdrücklich anders spezifiziert) und beim Methodenaufruf nicht automatisch initialisiert werden.
Aber Deinem Lösungsansatz kann ich auch was abgewinnen, tar. Die Beschaffung aller Spalten in einem großen VALUE zusammenzufassen ist auch ein sehr schöner und bei Verwendung funktionaler Methodenaufrufe auch übersichtlicher Ansatz. Allerdings würde ich im FOR-Block ein Feldsymbol verwenden, da das performanter ist und keine Nachteile hat.
Beitrag
von black_adept (Top Expert / 4087 / 126 /
940
)
»
Ich finde das eigentlich in bestimmten Situationen als recht nützlich. Beispiel: ABAP_BOOL Returning-Parameter um anzuzeigen ob etwas geklappt hat oder nicht und Exporting-Parameter BAPRET2_T, falls der Aufrufer sehen möchte was das Protokoll zu bieten hat. Das ermöglichtralf.wenzel hat geschrieben: ↑02.11.2024 10:46Richtig schräg (um nicht das andere Wort mit sch.... zu verwenden) finde ich Methoden (gibts auch von der SAP), die EXPORTING *und* RETURNING-Parameter haben.
Code: Alles auswählen.
IF NOT me->dosomething( EXPORTING ...
IMPORTING et_log = DATA(lt_log) ).
me->display_log( lt_log ).
ENDIFCHANGING/EXPORTING sind FuBa-Relikte - TABLES hat man doch auch weggeworfen, warum diese beiden nicht gleich mit? Seltsam, dass man RETURNING in ABAP nicht erzwingt, wo doch dessen konsequente Durchsetzung zu besser wiederverwendbarem Code und einer sauberen Formatierung führen würde.DeathAndPain hat geschrieben: ↑02.11.2024 20:47Aber solange man einfach ein Feld ändern möchte und für eine über den konkreten Anwendungsfall hinaus gehende Flexibilität gar keine Verwendung hat, finde ich es abwegig, sich auf eine Syntax festzulegen.
Falls man mehrere Rückgabewerte benötigt, kann man das über eigene Typisierungen lösen und wundersamerweise gibt es im OO das Klassenkonzept.
Aber wozu überhaupt über CHANGING/EXPORTING und RETURNING umhersinnen, wenn doch auch das geht: 😜
Code: Alles auswählen.
class lcl_land definition.
public section.
data:
id type t005-land1,
sprache type t005-spras.
methods:
constructor importing iv_id type t005-land1.
endclass.
class lcl_land implementation.
method constructor.
select single land1 as id,
spras as sprache
into (@id, @sprache)
from t005
where land1 = @iv_id.
endmethod.
endclass.
class lcl_helper definition.
public section.
types:
ltty_t005 type standard table of t005 with empty key.
class-methods:
setze_landessprache importing io_land type ref to lcl_land
iv_sprache type t005-spras.
endclass.
class lcl_helper implementation.
method setze_landessprache.
io_land->sprache = iv_sprache. " shoot the coder
endmethod.
endclass.
start-of-selection.
data(lo_land) = new lcl_land( 'DE' ).
end-of-selection.
write:/ 'vorher: ', lo_land->sprache.
lcl_helper=>setze_landessprache(
io_land = lo_land
iv_sprache = 'E'
).
write:/ 'nachher: ', lo_land->sprache.
Beitrag
von black_adept (Top Expert / 4087 / 126 /
940
)
»
Du kommst aus der Java-Welt, wo alles über Objekte geht und man keine änderbaren Parameter in Modularisierungseinheiten verwendet, oder einer anderen, rein objektorientierten Sprache?tar hat geschrieben: ↑03.11.2024 01:23CHANGING/EXPORTING sind FuBa-Relikte - TABLES hat man doch auch weggeworfen, warum diese beiden nicht gleich mit? Seltsam, dass man RETURNING in ABAP nicht erzwingt, wo doch dessen konsequente Durchsetzung zu besser wiederverwendbarem Code und einer sauberen Formatierung führen würde.
Falls man mehrere Rückgabewerte benötigt, kann man das über eigene Typisierungen lösen und wundersamerweise gibt es im OO das Klassenkonzept.
Schau mal in andere Sprachen wie C, Delphi, von mir aus auch VBA oder viele, wo die Parameterübergabe "by Reference" gang und gäbe ist.
ABAP hat seine Besonderheiten und du solltest diese umarmen und an den Stellen verwenden wo sie für dich nützlich sind, aber nicht versuchen Paradigmen und Wissen, was für andere Sprachen gilt, für ABAP zu postulieren.
Ich wiederhole mich, aber ich sage es gerne noch mal. Es ist weder gut in JAVA C++-Programme zu schreiben noch in ABAP JAVA-Programme.
ABAP genau so touring-vollständig wie all die anderen und somit weder besser noch schlechter als die gängigen anderen Sprachen. Aber jede Sprache hat ihren Zweck und Einsatzbereich und dementsprechend halt an einigen Stellen Vor- aber auch Nachteile. ( Abgesehen von so Sprachen wie Brainfuck, Shakespeare oder TrumpScript, die eigentlich fast nur Nachteile haben )
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
DeathAndPain
Nun, in C# werden bspw. Parameter via Referenzen genauso genutzt. Aber das ist nicht der Punkt. Es geht (wie im verlinkten Beitrag angemerkt) darum, Methoden allgemein verwendbar zu machen, d.h. Method-Chaining zu ermöglichen und notwendige Prädeklarationen zu vermeiden. Dass damit auch eine einheitliche Formatierung herbeigeführt wird, ist ein netter Bonus. Das halte ich für nachvollziehbarer als "CHANGING nutzt man, weil es was ändert" oder "EXPORTING nutzt man, wenn man mehrere Rückgaben braucht".
Kann man alles machen - übrigens auch in C#, nur mit anderer Syntax. Gerade deine Erfolgsrückmeldung (RETURNING boolean und eigentliche Rückgabe im CHANGING/EXPORTING) erinnert bspw. an die TryParse-Methoden in C#. Da spricht ja nichts dagegen, nur sollte man das nicht zur Hausregel erheben, "weil was geändert wird", gerade wenn es per entsprechend typisiertem RETURNING auch umsetzbar wäre und genannte Vorteile brächte.
Kann man alles machen - übrigens auch in C#, nur mit anderer Syntax. Gerade deine Erfolgsrückmeldung (RETURNING boolean und eigentliche Rückgabe im CHANGING/EXPORTING) erinnert bspw. an die TryParse-Methoden in C#. Da spricht ja nichts dagegen, nur sollte man das nicht zur Hausregel erheben, "weil was geändert wird", gerade wenn es per entsprechend typisiertem RETURNING auch umsetzbar wäre und genannte Vorteile brächte.
Beitrag
von DeathAndPain (Top Expert / 1939 / 257 /
412
)
»
Diese Meinung von Dir teile ich nicht.tar hat geschrieben:CHANGING/EXPORTING sind FuBa-Relikte
TABLES war überflüssig, weil die Feldtypen halt Tabellen sein können. Damit braucht man TABLES nicht mehr. (Das Kopfzeilenverhalten von TABLES hat die Sache nicht übersichtlicher gemacht, aber das war in meinen Augen nicht der ausschlaggebende Faktor.)tar hat geschrieben:TABLES hat man doch auch weggeworfen, warum diese beiden nicht gleich mit?
CHANGING und EXPORTING hingegen sind nicht überflüssig. RETURNING VALUE() kann sie nicht zufriedenstellend ersetzen. Das fängt schon bei der Performance an, da RETURNING immer eine Wertübergabe erfordert. Zudem kann man mit RETURNING nur einen einzigen Wert übergeben. Ich weiß, dass die SAP empfiehlt, anstatt mehrerer Parameter eine Struktur mit den Einzelwerten zu übergeben. Das habe ich in meinen Programmen ausprobiert und war nicht zufrieden, da es sich mies gelesen hat.
Eine Struktur ist gut, wenn sie tatsächlich zusammengehörende Werte zusammenfasst oder vielleicht auch, wenn sehr viele verschiedene Felder zu übergeben sind, so dass eine ellenlange Parameterliste entstehen würde. Allerdings kann ich mich an keinen einzigen Fall erinnern, bei dem ich das gebraucht hätte, ohne dass die ganzen Felder in einem Sinnzusammenhang stehen, der es rechtfertigt, sie in einer Struktur (die für etwas steht) zusammenzufassen (Ralf würde da hektisch gleich wieder ein OO-Objekt draus machen). Der Regelfall, so wie ich ihn erlebe, besteht darin, dass wir bei Methoden, bei denen ein Parameter (egal ob rein oder raus) nicht ausreicht, von lediglich zwei oder drei Feldern reden. Und da finde ich ein EXPORTING/CHANGING/IMPORTING, in dem diese Parameter - sprechend benamt - untereinander aufgeführt sind, wunderbar lesbar. Stattdessen ein Parameter mit einem Namen wie PARAMETERSTRUKTUR (weil es keinen besseren Namen gibt, weil die Parameter eben keine gemeinsame semantische Einheit bilden), gefällt mir überhaupt nicht.
Aus meiner Sicht gilt an dieser Stelle wieder das Prinzip, dass man sich nicht sklavisch Paradigmen unterwerfen sollte, die oft oder vielleicht auch meistens gut, zuweilen aber auch nachteilhaft sind. Ich bin da ein ganz großer Fan von gesundem Menschenverstand, bei dem ein Entwickler sagen darf, dass es sich in diesem Fall anders besser liest. Und wie gesagt: Nach meiner Erfahrung ist eine Parameteranzahl von zwei oder drei Parametern sogar der Regelfall. Wenn ich beispielsweise Kundendaten eines Kunden lesen möchte, dann brauche ich seine Kundennummer und den Stichtag, zu dem die Daten gelesen werden sollen. Die Daten, die ich zurückbekomme (Name des Kunden, Anschrift, Jahresumsatz mit mir usw.), sind dann durchaus eine semantische Einheit. Da könnte man dann gut eine Struktur für verwenden. Das sähe dann so aus:
Code: Alles auswählen.
DATA(kundendatenstruktur) = kundendaten_ermitteln( kunnr = kundennummer
stichtag = p_datum )." Parameter aus SelektionsbildCode: Alles auswählen.
DATA: begin of kundenanfragestruktur,
kunnr TYPE kunnr,
stichtag TYPE d,
end of of kundenanfragestruktur.
kundendatenstruktur = kundendaten_ermitteln( kundenanfragestruktur. ).
Beitrag
von black_adept (Top Expert / 4087 / 126 /
940
)
»
M.E. eben so wichtig ist, dass diese Parameter optional sein können und mittels "IS SUPPLIED" die Laufzeit beeinflussen können, wenn sie nicht angefordert werden. Außerdem ist ist es hier ein Einfaches eine generische Typisierung zu verwenden.DeathAndPain hat geschrieben: ↑04.11.2024 13:07CHANGING und EXPORTING hingegen sind nicht überflüssig. RETURNING VALUE() kann sie nicht zufriedenstellend ersetzen. und noch ein paar weitere richtige Anmerkungentar hat geschrieben:CHANGING/EXPORTING sind FuBa-Relikte
Kann man alles auch anders lösen, aber das ist halt der Sprachumfang von ABAP den ich an dieser Stelle liebe weil es alle Erwartungen in der Schnittstelle gut sichtbar bereitstellt.
Keine Mensch hat gesagt, dass man nur einen Import-Parameter verwenden soll 🧐DeathAndPain hat geschrieben: ↑04.11.2024 13:07Nach meiner Erfahrung ist eine Parameteranzahl von zwei oder drei Parametern sogar der Regelfall. Wenn ich beispielsweise Kundendaten eines Kunden lesen möchte, dann brauche ich seine Kundennummer und den Stichtag, zu dem die Daten gelesen werden sollen. Die Daten, die ich zurückbekomme (Name des Kunden, Anschrift, Jahresumsatz mit mir usw.), sind dann durchaus eine semantische Einheit. Da könnte man dann gut eine Struktur für verwenden.
Beitrag
von DeathAndPain (Top Expert / 1939 / 257 /
412
)
»
Es gibt keinen qualitativen Unterschied zwischen Import- und Export-Parametern. Warum sollten mehrere Import-Parameter statthaft sein, aber mehrere Export-Parameter nicht? Nur weil man unbedingt RETURNING verwenden soll und RETURNING mehrere Parameter nicht kann? Das finde ich zwanghaft und unbegründet.
Mir fällt grad bei diversen SAP-Demo-Paketen (SDYNAMICDOCUMENTS, SALV_IDA_TEST, ...) auf, dass in den darin angelegten Klassen ständig Methoden mit einem einzigen Rückgabeparameter als EXPORTING implementiert sind. Damit schreibt sich alles so unnötig umständlich.
Folgende Benutzer bedankten sich beim Autor tar für den Beitrag:
ralf.wenzel
Vergleichbare Themen
7
Antw.
Antw.
694
Views
Views
3
Antw.
Antw.
2230
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.