Umherspringende Methoden im quelltextbasierten Class Builder

Getting started ... Alles für einen gelungenen Start.
101 Beiträge • Vorherige Seite 7 von 7 (current)
101 Beiträge Vorherige Seite 7 von 7 (current)

Re: Umherspringende Methoden im quelltextbasierten Class Builder

Beitrag von DeathAndPain (Top Expert / 1916 / 249 / 407 ) »
ralf.wenzel hat geschrieben:
30.10.2024 20:50
Oder 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?
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:50
REFRESH war ausschließlich im Kontext von Tabellen mit Kopfzeilen sinnvoll, weil deren Name nicht eindeutig war. Klar, CLEAR[] ging auch....
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.
DeathAndPain hat geschrieben:
30.10.2024 20:43
Nein, eben nicht. Du hast meinen Mathelehrer nicht verstanden. Schon damals war p/q-Formel keine Mathematik.
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.
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.
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.

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


Re: Umherspringende Methoden im quelltextbasierten Class Builder

Beitrag von ralf.wenzel (Top Expert / 3917 / 199 / 280 ) »
DeathAndPain hat geschrieben:
31.10.2024 10:47
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.
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:47
schon damals nicht notwendig war
Richtig. Ein Grund mehr, es zu ignorieren.
DeathAndPain hat geschrieben:
31.10.2024 10:47
Ob das Ganze Sinn ergibt oder gar besser lesbar und verständlich ist, ist eine andere Frage.
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:47
Dennoch war Deine Aussage falsch. Du magst eine interne Tabelle in einem Objekt kapseln können, aber eine interne Tabelle ist kein Objekt.
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".


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Umherspringende Methoden im quelltextbasierten Class Builder

Beitrag von gtoXX (Specialist / 213 / 44 / 36 ) »
DeathAndPain hat geschrieben:
30.10.2024 16:16
gtoXX hat geschrieben:SAP schreibt im strikten Modus INTO immer als letzten Teil der Select Anweisung vor.
Da 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:CLEAR zu verwenden, wobei die gute Frage ist warum das uneindeutig sein soll, dass kann man eher über REFRESH sagen
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.
Der strikte Modus ist nicht deine Beschreibung, sondern immer, wenn eine Inlinedeklaration verwendet wird.

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 ^^"

Re: Umherspringende Methoden im quelltextbasierten Class Builder

Beitrag von gtoXX (Specialist / 213 / 44 / 36 ) »
ralf.wenzel hat geschrieben:
30.10.2024 11:20
gtoXX hat geschrieben:
30.10.2024 11:12
Warum? Hätte viele Vorteile.
Richtig. 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 ^^"

Re: Umherspringende Methoden im quelltextbasierten Class Builder

Beitrag von black_adept (Top Expert / 4066 / 120 / 934 ) »
@strict mode: Bevor hier noch weitere irgendein Halbwissen verbreiten möchten. SAP definiert den strict mode hier.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Umherspringende Methoden im quelltextbasierten Class Builder

Beitrag von black_adept (Top Expert / 4066 / 120 / 934 ) »
ralf.wenzel hat geschrieben:Es klappt ja nichtmal ein SWITCH in einer WHERE-Bedingung.
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
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Umherspringende Methoden im quelltextbasierten Class Builder

Beitrag von DeathAndPain (Top Expert / 1916 / 249 / 407 ) »
ralf.wenzel hat geschrieben:
31.10.2024 10:54
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.
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 hat geschrieben:Es gibt Schreibweisen, die auch komplexe Berechnungen zulassen, ADD und seine Brüder und Schwestern können das nicht.
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.
gtoXX hat geschrieben:Der strikte Modus ist nicht deine Beschreibung, sondern immer, wenn eine Inlinedeklaration verwendet wird.
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.

Und dennoch erfordert der strikte Modus nicht, dass INTO hinter FROM steht. Probier es gerne aus.
black_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
Nach meinem Verständnis meint Ralf sowas wie

Code: Alles auswählen.

SELECT * FROM MARA WHERE MATKL = SWITCH #( xyz WHEN 1 THEN 'ABC' ELSE 'DEF' ).

Re: Umherspringende Methoden im quelltextbasierten Class Builder

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

Re: Umherspringende Methoden im quelltextbasierten Class Builder

Beitrag von tar (ForumUser / 82 / 20 / 27 ) »
Die Unterscheidung gehört halt vor das SELECT:

Code: Alles auswählen.

data(lv_materialklasse) = cond matkl(
  when xyz = '00001' then 'ABC'
  else                    'DEF'
).

select ... where matkl = @lv_materialklasse.
Falls Ralf gesonderte SELECT-Ergebnisse meinte, dann sollte man sich daran halten und nach dem SELECT filtern.

Re: Umherspringende Methoden im quelltextbasierten Class Builder

Beitrag von rob_abc (ForumUser / 93 / 22 / 39 ) »
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):
DeathAndPainblack_adepttar


Re: Umherspringende Methoden im quelltextbasierten Class Builder

Beitrag von DeathAndPain (Top Expert / 1916 / 249 / 407 ) »
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.
tar hat geschrieben:Die Unterscheidung gehört halt vor das SELECT:
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.

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.
2821
Views
Top-Includes im Class-Builder
von mwcem » 27.06.2006 16:39 • Verfasst in ABAP Objects®
3
Antw.
5108
Views
Interne Tabelle in Class Builder definieren
von mamaierhofer » 20.03.2007 16:14 • Verfasst in ABAP Objects®
5
Antw.
6702
Views
Abstrakte Methode im Class Builder anlegen
von jay-tee » 18.12.2006 14:22 • Verfasst in ABAP Objects®
5
Antw.
3231
Views
Class Builder: Default für Meth.param. gepackt mit Dezimalen
von Gast » 06.02.2006 13:57 • Verfasst in ABAP Objects®
0
Antw.
2501
Views
Solution Builder (Build Block Builder)
von SAP_ENTWICKLER » 19.12.2018 09:59 • Verfasst in Sonstige Module

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.