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.
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.
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
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
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.
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.
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' ).
Code: Alles auswählen.
data(lv_materialklasse) = cond matkl(
when xyz = '00001' then 'ABC'
else 'DEF'
).
select ... where matkl = @lv_materialklasse.
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
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: