Wann kann man boolesche Werte in IFs direkt nutzen?

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

Re: Wann kann man boolesche Werte in IFs direkt nutzen?

Beitrag von Daniel (Specialist / 314 / 68 / 44 ) »
ralf.wenzel hat geschrieben:Das ist eine funktionale Methode, die nur den conversion exit aufruft. Die schreibt man einmal und genießt die (in meinen Augen durchaus vorhandenen Vorteile) immer wieder.

"Völliger Unfug" sagt Daniel dazu wörtlich. Ich habe ihm geschrieben, in welchem Kontext das sinnvoll ist, weil man dann eben nicht diesen coding-zerschneidenden "geschwätzigen Codingblock" ggf. mit Hilfsvariablen einbauen muss (den ICH subjektiv als leseerschwerend empfinde, muss nicht jeder so sehen), sondern das Ergebnis dieser Methode an funktionalen Operandenpositionen einsetzen kann. Für bestimmte Konvertierungen ist es darüber hinaus sinnvoll, den Eingabewert zu verproben, damit kein Müll rauskommt, was man dann zentral einbauen kann.
Ob man eine Methode oder eine Funktion aufruft macht kaum einen Unterschied
im Coding. Ich kann die Stellen des Aufrufs ja posten - die sind einfach nur im
laufenden Coding eingefügt. Der Conversion-Exit benötigt auch keine Hilfsvariablen.
Das verschachteln von Funktionen im Methoden ist nicht nur Unsinn sondern auch
höchst gefährlich. Viele Funktionen müssen in einer bestimmten Reihenfolge gerufen
werden. Beispielsweise der MB_CREATE_GOODS_MOVEMENT. Ruft man Ihn ein zweites
Mal bevor man den MB_POST_GOODS_MOVEMENT gerufen und comittet hat bricht er
ab weil das nicht zulässig ist. Wird der Aufruf allerdings in einer Methode verschalt
bemerkt er den wiederholten Aufruf nicht. So kann man mehrere Belege erzeugen
und buchen. Einige Zeit späte stellt man dann fest daß weder die Verbräuche noch
die Statistiken fortgeschrieben wurden und die Disposition zu wenig Material für die
laufende Fertigung bereitgestellt hat. Schaden über 2 Mio. Euro!
Wenn man in 00 programmieren will dann muß an das auch in Reinform praktizieren.
Für die Mischschform ist das System nicht ausgelegt. Daher ist solches Vorgehen nur
als anfängliches Unvermögen zu bezeichen.
ralf.wenzel hat geschrieben:Aus diesen zwei Gründen habe ich in Absprache mit internen Entwicklern diese Klasse und auch die gezeigte Methode geschrieben
Die beiden haben das lediglich zur Kenntnis genommen. Und BA-Studenten die seit
2 Jahren am System arbeiten sind evtl. die falschen Ansprechpartner.
ralf.wenzel hat geschrieben:Erfahrenen Entwicklern unterstelle ich grundsätzlich zunächst immer, dass sie sich dabei was gedacht haben, was sie tun.
Ja, das setzt aber aus wenn es nicht mehr um die Sache sondern um Ideologien geht.
ralf.wenzel hat geschrieben:Aber bestimmte Leute, die hier schreiben, als hätten sie das Rad erfunden, deklarieren einfach schnell alles als Unfug, was / wessen Kontext sie nicht verstehen. Alles Unfug - SAPUI5, OO, ABAP 7.40 mit seinen Kurzformen, Polymorphie. Und die bei der SAP, die das machen, haben nicht etwa eine unbekannte Motivation, sie sind Dilettanten, die keine Ahnung haben.
Nicht alles ist Unfug, nicht alle sind Dilettanten. Einiges und Einige schon.
ralf.wenzel hat geschrieben:Ein Blutspendedienst will keinen PC zum Blutspendetermin schleppen, wenn ein Tablet für die Datenerfassung reicht und außerdem eine Kamera eingebaut ist, mit der man beliebige Bar-/QR-Codes lesen kann, die auf Blutspendeausweisen und Proben vorhanden sind. Da kann man sich als Entwickler im Kreis drehen und Sch... schreien, der Anwender ist der Boss.
Evtl. erinnerst du dich daß ich die Anwendung für Auftragserfassung auf dem Ipad
hier entworfen habe? Der Zugriff von außen ist in dieser Applikation aber auf die
Aufgabe beschränkt.
ralf.wenzel hat geschrieben:Für jemanden mit einem Hammer ist jedes Problem ein Nagel.
Genau. Und deshalb ist 00 nur eines von vielen Werkzeugen. Man wähle das für
die Aufgabe geeignete. Wenn ich dann sehe daß jemand für ein Hello-World-Prog
eine Methode aufmacht sind wir genau bei dem Hammer. Das ist Blödsinn.

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


Re: Wann kann man boolesche Werte in IFs direkt nutzen?

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Ja, die Auftragserfassung kenne ich mit all ihren Limitierungen. Und sie haben es nicht zur Kenntnis genommen, sondern diskutiert und ausgebaut. Ich habe nach wie vor Kontakt mit Ihnen. Mit deinem in der Tat kritischen Beispiel hat meines nichts zu tun. Natürlich muss man wissen, was man tut, aber eine on-the-fly-Konvertierung ist keine Materialbuchung.


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

Re: Wann kann man boolesche Werte in IFs direkt nutzen?

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
Daniel hat geschrieben: Ob man eine Methode oder eine Funktion aufruft macht kaum einen Unterschied
im Coding. Ich kann die Stellen des Aufrufs ja posten - die sind einfach nur im
laufenden Coding eingefügt.

Aber doch einen wichtigen Unterschied, wie Ralfs Beispiel anschaulich zeigt.
Daniel hat geschrieben: Das verschachteln von Funktionen im Methoden ist nicht nur Unsinn sondern auch
höchst gefährlich.

Programmieren an sich ist gefährlich...
Daniel hat geschrieben:Viele Funktionen müssen in einer bestimmten Reihenfolge gerufen
werden. Beispielsweise der MB_CREATE_GOODS_MOVEMENT. Ruft man Ihn ein zweites
Mal bevor man den MB_POST_GOODS_MOVEMENT gerufen und comittet hat bricht er
ab weil das nicht zulässig ist. Wird der Aufruf allerdings in einer Methode verschalt
bemerkt er den wiederholten Aufruf nicht.
Daniel hat geschrieben: Da hätte ich ja gerne einen Beweis für, dass die Verschalung damit zu tun hat...
Und gerade mit einer Verschalung kann man solche Umstände, super in der Schale abbilden und entsprechend reagieren.
Daniel hat geschrieben:Wenn man in 00 programmieren will dann muß an das auch in Reinform praktizieren.
Für die Mischschform ist das System nicht ausgelegt. Daher ist solches Vorgehen nur
als anfängliches Unvermögen zu bezeichen.
Das ist ja nun auch großer Quatsch!
Daniel hat geschrieben: Wenn ich dann sehe daß jemand für ein Hello-World-Prog
eine Methode aufmacht sind wir genau bei dem Hammer. Das ist Blödsinn.
Ein Hello-World-Programm hat wohl auch kaum die Aufgabe, "Hello world" auszugeben...

Ich gebe Ralf in seiner Argumentation voll und ganz Recht. OO bietet viele Vorteile, die man nutzen sollte.
Und ja, oftmals hat man etwas mehr Aufwand. Aber gerade im SAP-System leben wir in einem Ökosystem, in dem die vorhandenen Programme auch gewartet werden müssen. Und gerad da bietet OO viele Vorteile. Von Testklassen bis hin zu sauberen Schnittstellen, wodurch eine Funktion schnell durch eine andere ausgetauscht werden kann.

OO ist nicht die eierlegende Wollmilchsau. Aber es ist auch nicht der Teufel, der alles nur unnötig kompliziert macht.

Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
ralf.wenzel


Re: Wann kann man boolesche Werte in IFs direkt nutzen?

Beitrag von Daniel (Specialist / 314 / 68 / 44 ) »
Es ist ein Werkzeug daß man verwendet wenn es geeignet ist.
Nicht mehr und nicht weniger.
Eine Testumgebung und saubere Schnittstellen gab es lang vor 00.

Re: Wann kann man boolesche Werte in IFs direkt nutzen?

Beitrag von Daniel (Specialist / 314 / 68 / 44 ) »
ralf.wenzel hat geschrieben:Und sie haben es nicht zur Kenntnis genommen, sondern diskutiert und ausgebaut.
Nö. Sieht immer noch so aus (Nur ein Beispiel):

Code: Alles auswählen.

      TRY.
          " this statement has to be that complex: we do need SERNR in table extension_in in CHAR18 format to convert it to GERNR format
          " otherwise, we'll get CX_SY_CONVERSION_NO_NUMBER dumps
          sernr = zcl_abap_conversion_exits=>conversion_exit_gernr_input( CONV char18( me->zif_app_cluster~extension_in[ structure  = 'SERNR' valuepart2 = <item>-itm_number ]-valuepart1 ) ).
        CATCH cx_sy_itab_line_not_found.
          " no equipment
          CONTINUE.
      ENDTRY.
Die Entwickler des Kunden weigern sich das Programm zu warten.
Deshalb habe ich es jetzt leider an der Backe.

Re: Wann kann man boolesche Werte in IFs direkt nutzen?

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
DeathAndPain hat geschrieben:Bei dem von Dir genannten kleinen Programm erweitere ich halt rasch neben der Formroutine auch die Aufrufe. Dort, wo der Parameter nicht benötigt wird, übergebe ich halt SPACE oder 0. Das dauert nicht lange, und wenn ich das als Literal (bzw. SPACE als Naturkonstante :-D ) übergebe, dann ist auch dem Leser klar, dass diese Parameter hier keine relevanten Daten transportieren.
Habe ich jahrelang auch so gemacht und erwische mich immer noch von Zeit zu Zeit dabei. Allerdings habe ich auch genug kleine Programme geschrieben, die in den folgenden Jahren zu immer größeren Gebilden gewuchert sind und wo man sich dann beim Einfügen eines neuen Schalters ärgert, wenn man auf einmal 10-20 Aufrufe vorfindet, die angepasst werden müssen.
DeathAndPain hat geschrieben:Doch der Preis, den man dafür zahlt, ist hoch, denn man muss extra eine (statische) Klasse definieren, dann eine Methodendefinition schreiben, dann eine Methodenimplementation schreiben, bei der man hoffentlich alle Parameter auswendig im Kopf hat, denn bei lokalen Methoden stehen die ja nicht am Anfang der Form, sondern ggf. am anderen Ende des Programms, [...] Der ganze Mülloverhead halt, den das OO erzwingt.
Ich frage mich trotzdem was an dem Overhead jetzt so schlimm ist.
  • Wenn dich die Schreibarbeit stört.
    Ein kleines Muster kann dir den Rumpf einer Hilfsklasse ( mit statischen Methoden gerne ) inkl. Definition und Implementierung direkt anlegen.
  • Wenn dich der Lesefluss stört.
    Dann ist das Programm an sich aber schon unleserlich. Ich überlese sinnlose Kommentare und für mich unwichtige Definitionen/Deklarationen. Das Interessante ist der Code - und dort siehst du den Teil normalerweise nicht
  • Alle Parameter auswendig...
    Bei solchen Hilfsmethoden ist bei mir die Anzahl der Parameter recht überschaubar - da muss ich mir nicht viel merken in der Implementierung und wenn man einer sinnvollen (eigenen) Namenskonvention folgt kann man den Namen auch ableiten ohne nachzuschauen
  • Signatur der Methode fehlt in Implementierung
    Das ist der einzige Punkt, der mich auch stört weil ich 1x mehr klicken muss. Naja - bei komplizierteren Methoden habe ich mir angewöhnt die Definition als Kommentar vor die Implementierung zu schreiben - das hilft zumindest.
DeathAndPain hat geschrieben:Solche Miniklassen packe ich aber auch ketzerischerweise ins TOP-Include, wo sie zusammen mit dem ganzen übrigen Definitionskram aus meinem tatsächlichen Code herausgehalten werden.
Was ist daran ketzerisch? Definitionen - egal ob von Variablen, Typen oder auch Objekte - gehören zusammen und wenn man mit TOP-Includes arbeiten möchte gehören die dann halt da hin.

Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 2):
ewxralf.wenzel

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Wann kann man boolesche Werte in IFs direkt nutzen?

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
Daniel hat geschrieben:Es ist ein Werkzeug daß man verwendet wenn es geeignet ist.
Nicht mehr und nicht weniger.
Jein. Es ist mehr, denke ich. Auch eine Philosophie.
Daniel hat geschrieben: Eine Testumgebung und saubere Schnittstellen gab es lang vor 00.
Saubere Schnittstellen: ja
Testumgebung: Wie sah die bitte aus?

Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
ralf.wenzel


Re: Wann kann man boolesche Werte in IFs direkt nutzen?

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
Übrigens ein lesenswerter Artikel, der auch noch gut zum Thema passt:

Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
ralf.wenzel


Re: Wann kann man boolesche Werte in IFs direkt nutzen?

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Und der insbesondere zeigt, wie sich jemand durch Fakten überzeugen ließ. Das hat bei mir auch gedauert, das gebe ich auch gern zu. Gegen OO habe ich lange geflucht, bis ich gelernt habe, was für geile Sachen ohne immensen Aufwand machbar werden.


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

Re: Wann kann man boolesche Werte in IFs direkt nutzen?

Beitrag von erp-bt (Specialist / 163 / 4 / 21 ) »
ewx hat geschrieben:Übrigens ein lesenswerter Artikel, der auch noch gut zum Thema passt:
Auch hierzu kann man eine andere Meinung haben. ;)

http://zevolving.com/2016/11/why-not-to ... ion-raise/

Viele Grüße, Tapio
...entwickelnder Berater...beratender Entwickler

Re: Wann kann man boolesche Werte in IFs direkt nutzen?

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Ein Hello-World-Programm hat wohl auch kaum die Aufgabe, "Hello world" auszugeben...
Doch, hat es. Das ist ja der Klassiker, den man als "Hello World"-Programm bezeichnet: einfach "Hello World" auszugeben als trivialstmöglichstes Beispiel eines Programms, das sichtbar was tut.
Und ja, oftmals hat man etwas mehr Aufwand. Aber gerade im SAP-System leben wir in einem Ökosystem, in dem die vorhandenen Programme auch gewartet werden müssen. Und gerad da bietet OO viele Vorteile. Von Testklassen bis hin zu sauberen Schnittstellen, wodurch eine Funktion schnell durch eine andere ausgetauscht werden kann.
Aber eben auch erhebliche Nachteile, gerade auch im Bereich der Wartung. Man ist viel mehr auf gute Doku angewiesen, um fremden Code zu verstehen, und wenn es die (wie immer) nicht gibt, dann ist man aufgeschmissen. Vor allem aber kann man den Debugger kaum noch nutzen. Der ist ja nicht nur ein nützliches Tool zur Fehlersuche, sondern oft auch die Rettung, wenn man Probleme hat, fremden Code zu verstehen (und bevor man ihn debuggt oder erweitert, muss man ja erst mal seine Arbeitsweise verstanden haben). Wenn der Code nur noch aus "selbstgemachten" Befehlen in Form von Objekten und Methoden besteht, deren Verhalten kontextabhängig ist (da er sich abhängig von in privaten Attributen versteckten Werten ändert) und bei denen man noch nicht mal das Sollverhalten kennt, dann tut man sich mit dem Debugger extrem schwer, sich darauf einen Reim zu machen.

Ralf pflegt an dieser Stelle vom hohen Ross herab zu antworten, na der Code darf halt nicht schlecht dokumentiert sein. Ist er aber fast immer (Thema "Theorie und Praxis" also). Bei prozeduralem Code kann man mit dem Debugger meist trotzdem noch was machen und nachvollziehen, was da passiert. Bei OO ist das eine ganz bittere Sache.

Klassisches Zitat, das ich an solchen Stellen gerne anbringe: "I don’t know the answer but I do know that debugging what happens after pressing a command in VA01 is easier to follow than the equivalent in ME21N. Or is that just because I am an OO novice?"
Ich frage mich trotzdem was an dem Overhead jetzt so schlimm ist.
...
  • Alle Parameter auswendig...
Bei solchen Hilfsmethoden ist bei mir die Anzahl der Parameter recht überschaubar
Solche Hilfsmethoden nutze ich ja in der von mir geschilderten Form. Aber das ist ja - ebenso wie übrigens auch Ralfs Konversionsmethode - letztlich alles statischer Kram. Mal abgesehen davon, dass es inhaltlich keine Punkte bringt, dafür eine Klasse definieren zu müssen, ist ja gerade die Frage, wie es bei "richtigen" Unterprogrammen, die mehr sind als nur eine kleine funktionale Methode und daher auch eine nennenswerte Latte von Parametern haben, aussieht. Und da kriege ich bei Methoden eine Macke. F2 in Eclipse ist eine Hilfe, aber keine perfekte Lösung.

Große Prozeduren prozedural und kleine Hilfsfunktionen OO - da gehe ich mit. Auch wenn ich mir für letztere eine Syntax mit weniger Wasserkopf (in der Definition) wünschen würde. Oder alternativ funktionale Prozeduren... na ja, die werden mit Sicherheit nicht kommen, aber träumen muss erlaubt sein.
  • Signatur der Methode fehlt in Implementierung
Das ist der einzige Punkt, der mich auch stört weil ich 1x mehr klicken muss. Naja - bei komplizierteren Methoden habe ich mir angewöhnt die Definition als Kommentar vor die Implementierung zu schreiben - das hilft zumindest.
Ja, das habe ich bei anderen OO-Programmierern auch schon gesehen. Aber das kann es doch nicht sein, dass man, nachdem man die Methode fertig definiert hat, noch händisch die ganzen Parameter in einen Kommentar an der Implementierung umkopieren muss. Abgesehen von dem an sich schon unzumutbaren Zusatzaufwand landen wir da dann ganz schnell auch wieder bei Deiner Anmerkung, was denn ist, wenn man mal einen Parameter ergänzt (oder löscht oder ändert). Schwupp stimmt der Kommentar nicht mehr, und Du darfst ihn auch wieder nachpflegen. Oder Du vergisst es, und der nächste Programmierer (oder Du selber) orientiert sich beim Bearbeiten der Methode dann an einer Schnittstellenbeschreibung, die nicht stimmt.

Es gibt einfach keinen praktischen Grund, Methoden in "Definition" und "Implementation" auseinanderzureißen. Akademisch wird sich das sicherlich begründen lassen, daran habe ich keine Zweifel. Aber das sind keine Begründungen, die in der praktischen Programmierung irgendeinen Wert hätten, sondern machen den Code dort nur voluminöser und schlechter lesbar.

Gipfeln tut das im (zum Glück optionalen) DEFINITION DEFERRED. Bei einer Formroutine ist es völlig egal, wo sie steht. Wenn es sie gibt, wird sie angesprungen. Eine Methode (oder Klasse) aber muss in der Reihenfolge vor dem Code stehen, der sie aufruft, sonst kennt er sie nicht. Was ist das für eine altertümliche Einschränkung? Da fühle ich mich ja fast an GOTO-Zeiten erinnert. Auch hier wieder: rein akademischer Grund; in der Praxis nicht mehr als ein Ärgernis.
Solche Miniklassen packe ich aber auch ketzerischerweise ins TOP-Include, wo sie zusammen mit dem ganzen übrigen Definitionskram aus meinem tatsächlichen Code herausgehalten werden.
Was ist daran ketzerisch? Definitionen - egal ob von Variablen, Typen oder auch Objekte - gehören zusammen und wenn man mit TOP-Includes arbeiten möchte gehören die dann halt da hin.
Ich kann mich erinnern, mir dafür vom System eine Meldung gefangen zu haben, in der ich belehrt wurde, dass solches Coding in einem Top-Include keinen "Sinn" machen würde (das Wort "Sinn" stand da wirklich drin!). Ich glaube, das war eine Warnung von der Syntaxprüfung, die als gelbes Dreieck in Eclipse hochkommt. Bin mir aber nicht mehr ganz sicher. Auf jeden Fall kam das. Fand ich schon ganz lustig, dass das System allein anhand des Include-Namens messerscharf (und nicht falsch) auf dessen Zweck schließt und mich belehrt, was da reingehöre und was nicht. Idiotisch fand ich es freilich auch.

Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Daniel


Re: Wann kann man boolesche Werte in IFs direkt nutzen?

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
DeathAndPain hat geschrieben:Gipfeln tut das im (zum Glück optionalen) DEFINITION DEFERRED. Bei einer Formroutine ist es völlig egal, wo sie steht. Wenn es sie gibt, wird sie angesprungen. Eine Methode (oder Klasse) aber muss in der Reihenfolge vor dem Code stehen, der sie aufruft, sonst kennt er sie nicht. Was ist das für eine altertümliche Einschränkung?[...]Auch hier wieder: rein akademischer Grund; in der Praxis nicht mehr als ein Ärgernis.
Nein - das ist ein Missverständnis deinerseits was dich dazu führt Äpfel mit Birnen zu vergleichen.
Eine Klassendefinition entspricht einer Typ-Definition. Und auch hier gilt im SAP: Wenn ich Typ A in Typ B verwenden möchte muss ich Typ A vorher im Coding deklariert haben.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Wann kann man boolesche Werte in IFs direkt nutzen?

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Ich finde die Bezeichnungen "praktisch" und "akademisch" ungünstig gewählt. Du vergleichst Parameter von Funktionsbausteinen mit Parametern von Methoden.

Das ist an sich schon ein Vergleich von Äpfeln mit Birnen - es sind zwar beides Parameter von Routinen, aber technisch unterscheiden sie sich stark. Insbesondere, weil die Signatur einer Methode Bestandteil der Klassenschnittstelle ist. DAS ist der Grund, warum die einfache Syntaxprüfung einen Typfehler in der Parameterübergabe erkennt und moniert, bei Funktionsbausteinen aber nicht (weil das viel zu lange dauern würde). Dazu braucht man dann die Erweiterte Programmprüfung mit "Teure übergreifende Prüfungen" (oder so ähnlich). Und DARUM werden die Parameter im DEFINITION-Teil deklariert und nicht im IMPLEMENTATION-Teil.

Das mag man umständlich nennen, aber es ist technisch (und nicht etwa akademisch) einfach richtig. Würde man die Parameter in de Implementierung definieren, wären sie leichter im Blick, aber man verlöre die Vorteile (siehe oben) ODER man spiegelt dem Entwickler etwas vor, was aber technisch ganz anders realisiert ist (was nicht gerade transparent ist).

Ich tue mich schwer, Funktionsgruppen mit Klassen zu vergleichen, weil das technisch sehr unterschiedliche Dinge sind. Insofern zeigt die Aussage (ich zitiere sinngemäß) "Funktionsgruppen sind sowas ähnliches wie ein Objekt, nur einfacher im Handling". Das stimmt in vielerlei Hinsicht nicht und DAS ist nur eine davon. Man kann eine Klasse so designen, dass sie ähnlich wie eine Funktionsgruppe verwendet werden kann, das ist dann aber auch alles und es ist insbesondere nicht die Regel. Dadurch, dass ich mit einem Flugzeug herumfahren kann, wird kein Auto draus.



Ralf *wenn DAS schon umständlich ist, versuch mal eine Frau zu verstehen :D
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Wann kann man boolesche Werte in IFs direkt nutzen?

Beitrag von Daniel (Specialist / 314 / 68 / 44 ) »
ralf.wenzel hat geschrieben:DAS ist der Grund, warum die einfache Syntaxprüfung einen Typfehler in der Parameterübergabe erkennt und moniert, bei Funktionsbausteinen aber nicht (weil das viel zu lange dauern würde). Dazu braucht man dann die Erweiterte Programmprüfung mit "Teure übergreifende Prüfungen" (oder so ähnlich).
Quatsch. Die Parameter der FBs stehen fein säuberlich in der Tabelle fupararef.
Die SAP hat die Prüfung einfach nicht implementiert. Die wäre weder teuer noch
dauert so etwas lange.

Folgende Benutzer bedankten sich beim Autor Daniel für den Beitrag:
DeathAndPain


Re: Wann kann man boolesche Werte in IFs direkt nutzen?

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
ralf.wenzel hat geschrieben:DAS ist der Grund, warum die einfache Syntaxprüfung einen Typfehler in der Parameterübergabe erkennt und moniert, bei Funktionsbausteinen aber nicht (weil das viel zu lange dauern würde)
DAS ist leider nicht der Grund. Der Grund ist, dass FuBa eigentlich immer dynamisch aufgerufen werden und SAP keinen statischen Aufruf vorgesehen hat. Das Dumme ist nur, dass der übliche Aufruf via Funktionsbausteinnamen ein dynamischer Aufruf mittels Literal ist, was zwar de facto dann ein statischer Aufruf ist aber vom Interpreter immer noch als dynamisch angesehen wird. Entspricht etwa folgendem dynamischen (aber de facto statischen) SELECT-Konstruct

Code: Alles auswählen.

SELECT ... FROM ('MARA') .....
Und das ist dann auch der Grund, warum die Parameter nicht überprüft werden ( und weil die Entwickler scheinbar keine Lust hatten das einfach nachzuziehen, was ja problemlos möglich wäre ), weil bei dynamischen Aufrufen normalerweise halt keine Prüfungen möglich sind.

Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 2):
ralf.wenzelDeathAndPain

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Vergleichbare Themen

7
Antw.
4220
Views
Werte direkt nach Eingabe ermitteln
von cschmoel » 27.08.2012 11:10 • Verfasst in ABAP® für Anfänger
4
Antw.
2701
Views
Abhängige Werte-Liste (F4-Werte)
von Gast » 27.12.2005 10:34 • Verfasst in ABAP® Core
2
Antw.
1785
Views
Kommunikation aus SAP direkt mit SPS
von Helmut Rückert » 15.10.2008 15:45 • Verfasst in ABAP® Core
13
Antw.
5610
Views
substring direkt in IF
von pherweg » 09.02.2018 17:08 • Verfasst in ABAP® Core
4
Antw.
5552
Views
SQL Befehle direkt absetzen
von Nautilus » 21.03.2006 15:53 • Verfasst in Basis

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 2 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

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.

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 2 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 2 Tagen von Lucyalison 1 / 64
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 107
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 140