Umherspringende Methoden im quelltextbasierten Class Builder
Beitrag
von DeathAndPain (Top Expert / 1939 / 257 /
412
)
»
Aus historischen Gründen, da sind wir uns ja einig. Aber da es den Befehl nun schon mal gibt, warum ihn nicht benutzen, um den Code anschaulicher zu gestalten? Bei ADD machen wir es ja genauso, und den gibt es ebenso nur aus historischen Gründen.ralf.wenzel hat geschrieben: ↑30.10.2024 20:50Oder erklär mir doch mal, warum es nicht besonderen Löschbefehle für Strukturen gibt. Und da es die nicht gibt: Warum für Tabellen?
Womit klar ist, dass der Befehl schon damals nicht notwendig war und nur aus Veranschaulichungsgründen verwendet wurde. Und das finde ich auch nicht verwerflich.ralf.wenzel hat geschrieben: ↑30.10.2024 20:50REFRESH war ausschließlich im Kontext von Tabellen mit Kopfzeilen sinnvoll, weil deren Name nicht eindeutig war. Klar, CLEAR[] ging auch....
Aber die Gültigkeit der p-q-Formel zu beweisen (was man anhand der binomischen Formeln bewerkstelligen kann), ist es sehr wohl. Dein Mathelehrer hat recht: Kochrezepte anzuwenden ist keine Mathematik. Kochrezepte zu finden und zu beweisen aber sehr wohl.DeathAndPain hat geschrieben: ↑30.10.2024 20:43Nein, eben nicht. Du hast meinen Mathelehrer nicht verstanden. Schon damals war p/q-Formel keine Mathematik.
Klar. Du kannst auch ein "Hello World" programmieren, indem Du einw Wortklasse baust, diese zweimal in Unterklassen vererbst (eine für "Hello" und eine für "World"), wobei dort dann jeweils das auszugebende Wort redefiniert wird, und am Ende hast Du aus dem Einzeiler einen zweiseitigen Code gemacht. Ob das Ganze Sinn ergibt oder gar besser lesbar und verständlich ist, ist eine andere Frage.Ralf hat geschrieben:Hä? Ich kann ein Auto, einen Beleg und sonstwas als Objekt betrachten, aber eine Tabelle nicht? Natürlich kann ich aus einer Tabelle ein Objekt machen, indem ich sie in einer Klasse verwalte.
Dennoch war Deine Aussage falsch. Du magst eine interne Tabelle in einem Objekt kapseln können, aber eine interne Tabelle ist kein Objekt.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Nein, ich benutze ADD nicht. Eine der Anweisungen, die nur nicht abgeschafft werden, damit sie noch funktionieren (Abwärtskompatibilität), aber die man nicht benutzen sollte. Es gibt Schreibweisen, die auch komplexe Berechnungen zulassen, ADD und seine Brüder und Schwestern können das nicht.DeathAndPain hat geschrieben: ↑31.10.2024 10:47Aus historischen Gründen, da sind wir uns ja einig. Aber da es den Befehl nun schon mal gibt, warum ihn nicht benutzen, um den Code anschaulicher zu gestalten? Bei ADD machen wir es ja genauso, und den gibt es ebenso nur aus historischen Gründen.
Richtig. Ein Grund mehr, es zu ignorieren.
Das ist ein sehr gutes Beispiel, wie man Entwicklern "alles ist ein Objekt" beibiegen kann, danke für den Tipp. Der Satz ist übrigens vom Erfinder der Objektorientierten Programmierer.DeathAndPain hat geschrieben: ↑31.10.2024 10:47Ob das Ganze Sinn ergibt oder gar besser lesbar und verständlich ist, ist eine andere Frage.
Naja, dann ist ein Beleg auch kein Objekt, sondern das Objekt, das den Beleg kapselt ist das Objekt. Landläufig sagt man aber "das Objekt ist der Beleg".DeathAndPain hat geschrieben: ↑31.10.2024 10:47Dennoch war Deine Aussage falsch. Du magst eine interne Tabelle in einem Objekt kapseln können, aber eine interne Tabelle ist kein Objekt.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Der strikte Modus ist nicht deine Beschreibung, sondern immer, wenn eine Inlinedeklaration verwendet wird.DeathAndPain hat geschrieben: ↑30.10.2024 16:16Da ist die Frage, was Du als "strikt" bezeichnest. Ich kenne den "strikten" Modus bei SELECT als den, bei dem man die Felder mit Komma aufzählen und alle Hostvariablen escapen muss. Und in diesem Modus darf durchaus INTO vor FROM stehen.gtoXX hat geschrieben:SAP schreibt im strikten Modus INTO immer als letzten Teil der Select Anweisung vor.
Diese Frage lässt sich leicht beantworten: Bei CLEAR geht aus dem Befehl nicht hervor, ob ein Feld oder eine interne Tabelle geleert wird (uneindeutig). REFRESH leert immer eine interne Tabelle und ist damit hundertprozentig eindeutig. Dabei spielt es keine Rolle, ob diese interne Tabelle eine Kopfzeile hat, und genau das macht REFRESH auch für moderne interne Tabellen tauglich.gtoXX hat geschrieben:CLEAR zu verwenden, wobei die gute Frage ist warum das uneindeutig sein soll, dass kann man eher über REFRESH sagen
Das INTO steht dabei IMMER am Ende, da aufgrund der Felder und Tabellen, die davor stehen der Typ des deklarierten Objekts bestimmt wird.
https://help.sap.com/doc/abapdocu_750_i ... 0_sp08.htm
Bezüglich des Clear/Refresh schließe ich mich Ralf an. Es ist völlig unerheblich, welchen Typ das Datenobjekt hat.
"Code lügt nicht ^^"
ralf.wenzel hat geschrieben: ↑30.10.2024 11:20Richtig. Aber es ist nicht denkbar, dass sie das macht. Es klappt ja nichtmal ein SWITCH in einer WHERE-Bedingung.
Ralf
In Kombination mit einer VALUE Anweisung sollte auch ein Switch funktionieren. https://help.sap.com/doc/abapdocu_750_i ... _abexa.htm
"Code lügt nicht ^^"
Beitrag
von black_adept (Top Expert / 4087 / 126 /
940
)
»
Wie soll denn das deiner Meinung nach aussehen bzw. was würdest du gerne schreiben? Und für welches WHERE? Datenbankzugriff wie z.B. SELECT oder LOOPralf.wenzel hat geschrieben:Es klappt ja nichtmal ein SWITCH in einer WHERE-Bedingung.
Beitrag
von DeathAndPain (Top Expert / 1939 / 257 /
412
)
»
Vor einiger Zeit (als Du noch inaktiv warst) wurde hier im Forum mal diskutiert, wie nützlich und gut lesbar ADD sei. In einer ungewöhnlichen Einigkeit waren sich alle Teilnehmenden einig, dass ADD sehr gut zu lesen ist (besser als a = a + 1 oder gar a += 1) und daher nach wie vor sehr nützlich ist, obwohl es von der SAP als veraltet eingestuft worden ist. Mit dieser Meinung stehst Du also alleine da.ralf.wenzel hat geschrieben: ↑31.10.2024 10:54Nein, ich benutze ADD nicht. Eine der Anweisungen, die nur nicht abgeschafft werden, damit sie noch funktionieren (Abwärtskompatibilität), aber die man nicht benutzen sollte.
Mit der gleichen Berechtigung könntest Du auch sagen, dass man nie SWITCH verwenden sollte, denn es gibt ja auch COND, mit dem man nicht nur alles machen kann, was SWITCH auch kann, sondern darüber hinaus beliebige logische Ausdrücke auswerten kann. Nur ist SWITCH halt häufig ausreichend und dann prägnanter lesbar - und genauso ist es mit ADD (und seinen Schwesterbefehlen wie SUBTRACT und MULTIPLY) eben auch.Ralf hat geschrieben:Es gibt Schreibweisen, die auch komplexe Berechnungen zulassen, ADD und seine Brüder und Schwestern können das nicht.
Andere Version: Der strikte Modus ist das, was ich beschrieben habe, und wenn man im SELECT eine Inlinedeklaration verwendet, wird er erzwungen, und man muss sich daran halten.gtoXX hat geschrieben:Der strikte Modus ist nicht deine Beschreibung, sondern immer, wenn eine Inlinedeklaration verwendet wird.
Und dennoch erfordert der strikte Modus nicht, dass INTO hinter FROM steht. Probier es gerne aus.
Nach meinem Verständnis meint Ralf sowas wieblack_adept hat geschrieben:Wie soll denn das deiner Meinung nach aussehen bzw. was würdest du gerne schreiben? Und für welches WHERE? Datenbankzugriff wie z.B. SELECT oder LOOP
Code: Alles auswählen.
SELECT * FROM MARA WHERE MATKL = SWITCH #( xyz WHEN 1 THEN 'ABC' ELSE 'DEF' ).
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Das ist nicht das erste Mal dass ich eine Meinung vertrete, die andere nicht haben. Bei meinem Kunden ist ADD übrigens verboten. ALLEIN stehe ich also nicht.
Zum SELECT: Ja, genau das meinte ich.
Ralf
Zum SELECT: Ja, genau das meinte ich.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Die Unterscheidung gehört halt vor das SELECT:
Falls Ralf gesonderte SELECT-Ergebnisse meinte, dann sollte man sich daran halten und nach dem SELECT filtern.
Code: Alles auswählen.
data(lv_materialklasse) = cond matkl(
when xyz = '00001' then 'ABC'
else 'DEF'
).
select ... where matkl = @lv_materialklasse.Die Syntax ist etwas gewöhnungsbedürftig. Das ermöglicht z.B. auch das verwenden von Methoden im WHERE.
Code: Alles auswählen.
REPORT.
DATA(value) = 'M'.
SELECT * from t006
where dimid = @( SWITCH #( value WHEN 'M' THEN 'MASS' ELSE 'LENGTH' ) )
into table @DATA(uoms).
cl_demo_output=>write( uoms ).
clear value.
SELECT * from t006
where dimid = @( SWITCH #( value WHEN 'M' THEN 'MASS' ELSE 'LENGTH' ) )
into table @DATA(uoms2).
cl_demo_output=>write( uoms2 ).
cl_demo_output=>display( ).Folgende Benutzer bedankten sich beim Autor rob_abc für den Beitrag (Insgesamt 3):
DeathAndPain • black_adept • tar
Beitrag
von DeathAndPain (Top Expert / 1939 / 257 /
412
)
»
Nice. Ich mag zwar das ganze Ge-escape im SELECT nicht, weil es hässlich und unübersichtlich aussieht, und das@ vor der Klammer setzt dem noch die Krone auf. Aber immerhin: wenn das funktioniert, was Du da geschrieben hast (habe ich jetzt auf die Schnelle nicht nachgeprüft), dann ist das ja schon mal was.
Mich stört schon, dass ich zum Erzeugen von Datenbanktabellenzeilen immer eine Workarea-Variable befüllen muss und nicht einfach sagen kann: INSERT dbtab FROM VALUE #( ... ). Das ist einfach unnötige Schikane (auch wenn es vielleicht das Debuggen etwas erleichtert).
Dass sie (bei herkömmlicher Notation) dort stehen muss, weil der ABAP-Compiler das sonst zurückweist, heißt nicht, dass sie dort hingehört. Ein einfacher SWITCH in der WHERE-Bedingung würde sich gut und elegant lesen. Stattdessen vorher ein Hilfsfeld deklarieren zu müssen, um damit dann im SELECT zu arbeiten, erinnert an ABAP-Releases vergangener Jahrzehnte und ist insofern ABAP-compilerseitig schlecht gemacht.tar hat geschrieben:Die Unterscheidung gehört halt vor das SELECT:
Mich stört schon, dass ich zum Erzeugen von Datenbanktabellenzeilen immer eine Workarea-Variable befüllen muss und nicht einfach sagen kann: INSERT dbtab FROM VALUE #( ... ). Das ist einfach unnötige Schikane (auch wenn es vielleicht das Debuggen etwas erleichtert).
Vergleichbare Themen
10
Antw.
Antw.
2884
Views
Views
3
Antw.
Antw.
5118
Views
Views
Interne Tabelle in Class Builder definieren
von mamaierhofer » 20.03.2007 16:14 • Verfasst in ABAP Objects®
von mamaierhofer » 20.03.2007 16:14 • Verfasst in ABAP Objects®
5
Antw.
Antw.
6724
Views
Views
Abstrakte Methode im Class Builder anlegen
von jay-tee » 18.12.2006 14:22 • Verfasst in ABAP Objects®
von jay-tee » 18.12.2006 14:22 • Verfasst in ABAP Objects®
5
Antw.
Antw.
3242
Views
Views
Class Builder: Default für Meth.param. gepackt mit Dezimalen
von Gast » 06.02.2006 13:57 • Verfasst in ABAP Objects®
von Gast » 06.02.2006 13:57 • Verfasst in ABAP Objects®
0
Antw.
Antw.
2536
Views
Views
Solution Builder (Build Block Builder)
von SAP_ENTWICKLER » 19.12.2018 09:59 • Verfasst in Sonstige Module
von SAP_ENTWICKLER » 19.12.2018 09:59 • Verfasst in Sonstige Module
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.