corresponding - mapping - switch

Alles rund um die Sprache ABAP®: Funktionsbausteine, Listen, ALV
44 Beiträge • Vorherige Seite 3 von 3 (current)
44 Beiträge Vorherige Seite 3 von 3 (current)

Re: corresponding - mapping - switch

Beitrag von DeathAndPain (Top Expert / 1916 / 249 / 407 ) »
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:

Code: Alles auswählen.

zielstruc = corresponding #( quellstruc mapping field1 = default switch #( lv_field1 when 'B' then 'B'
                                                                                              else 'P' ).
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.

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: corresponding - mapping - switch

Beitrag von tar (ForumUser / 81 / 18 / 27 ) »
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.

Re: corresponding - mapping - switch

Beitrag von DeathAndPain (Top Expert / 1916 / 249 / 407 ) »
tar hat geschrieben:
31.10.2024 21:33
Da fehlt aber eine Klammer, was bei deiner Formatierung halt nicht, bei meiner schlagartig auffällt 😉
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 finde das Konstrukt aber an sich schlecht und verwende CORRESPONDING außerhalb von SELECTs recht selten.
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:

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 ).
Das ist nicht nur kurz und gut lesbar, sondern das FILTER-Konstrukt gilt auch als sehr performant (ein wesentlicher Vorteil zu Alternativen wie z.B. einem LOOP "zu Fuß"), und so kannst Du es elegant nutzen, ohne mit irgendwelchen Hilfstabellen hantieren zu müssen, die genauso typisiert sind wie puffer_lagerort. Ich vermute, dass FILTER von der SAP so gedacht worden ist, weil ich das ansonsten für eine sperrig designte Fehlkonstruktion halten würde.

Re: corresponding - mapping - switch

Beitrag von tar (ForumUser / 81 / 18 / 27 ) »
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:

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 ...
  )
).
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.

Re: corresponding - mapping - switch

Beitrag von ralf.wenzel (Top Expert / 3917 / 199 / 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
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: corresponding - mapping - switch

Beitrag von DeathAndPain (Top Expert / 1916 / 249 / 407 ) »
Ralf hat geschrieben:Im verlinkten Beitrag steht schon richtig: Wenn eine Methode eine Variable ändert, nimmt man CHANGING, schon um genau das anzuzeigen.
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.

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.

Re: corresponding - mapping - switch

Beitrag von black_adept (Top Expert / 4066 / 120 / 933 ) »
ralf.wenzel hat geschrieben:
02.11.2024 10:46
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.
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öglicht

Code: Alles auswählen.

IF NOT me->dosomething( EXPORTING ...
                        IMPORTING et_log = DATA(lt_log) ). 
  me->display_log( lt_log ).
ENDIF
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: corresponding - mapping - switch

Beitrag von tar (ForumUser / 81 / 18 / 27 ) »
DeathAndPain hat geschrieben:
02.11.2024 20:47
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.
CHANGING/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.

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.

Re: corresponding - mapping - switch

Beitrag von black_adept (Top Expert / 4066 / 120 / 933 ) »
tar hat geschrieben:
03.11.2024 01:23
CHANGING/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.
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?
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

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: corresponding - mapping - switch

Beitrag von tar (ForumUser / 81 / 18 / 27 ) »
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.

Re: corresponding - mapping - switch

Beitrag von DeathAndPain (Top Expert / 1916 / 249 / 407 ) »
tar hat geschrieben:CHANGING/EXPORTING sind FuBa-Relikte
Diese Meinung von Dir teile ich nicht.
tar hat geschrieben:TABLES hat man doch auch weggeworfen, warum diese beiden nicht gleich mit?
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.)

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 Selektionsbild
Das liest sich wunderbar. Verglichen damit mies lesen würde sich in meinen Augen:

Code: Alles auswählen.

DATA: begin of kundenanfragestruktur,
        kunnr TYPE kunnr,
        stichtag TYPE d,
      end of  of kundenanfragestruktur.

kundendatenstruktur = kundendaten_ermitteln( kundenanfragestruktur. ).
Da sieht man einfach wesentlich schlechter, was für Werte in die Methode reingehen; mit was für Werten die Methode also arbeitet. Das ist einfach krampfig, so nach dem Motto: "Meine (selbst auferlegte) Vorschrift ist, dass Methoden pro Richtung nur einen Parameter haben dürfen, also muss ich das hier auch so machen. Ob es hier in diesem Fall sinnvoll und nützlich ist, spielt keine Rolle, denn Vorschriften müssen eingehalten werden."

Re: corresponding - mapping - switch

Beitrag von black_adept (Top Expert / 4066 / 120 / 933 ) »
DeathAndPain hat geschrieben:
04.11.2024 13:07
tar hat geschrieben:CHANGING/EXPORTING sind FuBa-Relikte
CHANGING und EXPORTING hingegen sind nicht überflüssig. RETURNING VALUE() kann sie nicht zufriedenstellend ersetzen. und noch ein paar weitere richtige Anmerkungen
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.
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.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: corresponding - mapping - switch

Beitrag von tar (ForumUser / 81 / 18 / 27 ) »
DeathAndPain hat geschrieben:
04.11.2024 13:07
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.
Keine Mensch hat gesagt, dass man nur einen Import-Parameter verwenden soll 🧐

Re: corresponding - mapping - switch

Beitrag von DeathAndPain (Top Expert / 1916 / 249 / 407 ) »
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.

Vergleichbare Themen

3
Antw.
9433
Views
Switch Case
von Spookykid » 07.04.2011 17:07 • Verfasst in ABAP® für Anfänger
7
Antw.
628
Views
Line_exists in Switch / for Schleife
von RaCDigger » 22.07.2022 10:19 • Verfasst in ABAP® Core
0
Antw.
1395
Views
OR Mapping
von yuro » 27.01.2015 00:11 • Verfasst in ABAP Objects®
6
Antw.
2862
Views
ABAP-Mapping
von Sniper_61 » 20.11.2008 22:40 • Verfasst in ABAP® für Anfänger
3
Antw.
2185
Views
Hilfe bei Mapping
von ABAP_User » 10.05.2011 17:49 • Verfasst in ABAP® für Anfänger

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.