Wann kann man boolesche Werte in IFs direkt nutzen?
Ob man eine Methode oder eine Funktion aufruft macht kaum einen Unterschiedralf.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.
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.
Die beiden haben das lediglich zur Kenntnis genommen. Und BA-Studenten die seitralf.wenzel hat geschrieben:Aus diesen zwei Gründen habe ich in Absprache mit internen Entwicklern diese Klasse und auch die gezeigte Methode geschrieben
2 Jahren am System arbeiten sind evtl. die falschen Ansprechpartner.
Ja, das setzt aber aus wenn es nicht mehr um die Sache sondern um Ideologien geht.ralf.wenzel hat geschrieben:Erfahrenen Entwicklern unterstelle ich grundsätzlich zunächst immer, dass sie sich dabei was gedacht haben, was sie tun.
Nicht alles ist Unfug, nicht alle sind Dilettanten. Einiges und Einige schon.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.
Evtl. erinnerst du dich daß ich die Anwendung für Auftragserfassung auf dem Ipadralf.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.
hier entworfen habe? Der Zugriff von außen ist in dieser Applikation aber auf die
Aufgabe beschränkt.
Genau. Und deshalb ist 00 nur eines von vielen Werkzeugen. Man wähle das fürralf.wenzel hat geschrieben:Für jemanden mit einem Hammer ist jedes Problem ein Nagel.
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
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
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
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
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...
Ein Hello-World-Programm hat wohl auch kaum die Aufgabe, "Hello world" auszugeben...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.
Das ist ja nun auch großer Quatsch!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.
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.
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
Nö. Sieht immer noch so aus (Nur ein Beispiel):ralf.wenzel hat geschrieben:Und sie haben es nicht zur Kenntnis genommen, sondern diskutiert und ausgebaut.
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.
Deshalb habe ich es jetzt leider an der Backe.
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
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: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) übergebe, dann ist auch dem Leser klar, dass diese Parameter hier keine relevanten Daten transportieren.
Ich frage mich trotzdem was an dem Overhead jetzt so schlimm ist.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.
- 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.
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.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.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 2):
ralf.wenzel • ewx
Jein. Es ist mehr, denke ich. Auch eine Philosophie.Daniel hat geschrieben:Es ist ein Werkzeug daß man verwendet wenn es geeignet ist.
Nicht mehr und nicht weniger.
Saubere Schnittstellen: jaDaniel hat geschrieben: Eine Testumgebung und saubere Schnittstellen gab es lang vor 00.
Testumgebung: Wie sah die bitte aus?
Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
ralf.wenzel
Übrigens ein lesenswerter Artikel, der auch noch gut zum Thema passt:
Paul Hardy hat geschrieben: https://blogs.sap.com/2016/10/29/harlem ... e-shuffle/
Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
ralf.wenzel
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
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
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Auch hierzu kann man eine andere Meinung haben.ewx hat geschrieben:Übrigens ein lesenswerter Artikel, der auch noch gut zum Thema passt:Paul Hardy hat geschrieben: https://blogs.sap.com/2016/10/29/harlem ... e-shuffle/
http://zevolving.com/2016/11/why-not-to ... ion-raise/
Viele Grüße, Tapio
...entwickelnder Berater...beratender Entwickler
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
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.Ein Hello-World-Programm hat wohl auch kaum die Aufgabe, "Hello world" auszugeben...
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.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.
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?"
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.Ich frage mich trotzdem was an dem Overhead jetzt so schlimm ist.
...Bei solchen Hilfsmethoden ist bei mir die Anzahl der Parameter recht überschaubar
- Alle Parameter auswendig...
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.
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.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.
- Signatur der Methode fehlt in Implementierung
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.
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.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.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.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Daniel
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Nein - das ist ein Missverständnis deinerseits was dich dazu führt Äpfel mit Birnen zu vergleichen.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.
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.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
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
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
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Quatsch. Die Parameter der FBs stehen fein säuberlich in der Tabelle fupararef.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).
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
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
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-Konstructralf.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)
Code: Alles auswählen.
SELECT ... FROM ('MARA') .....Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 2):
ralf.wenzel • DeathAndPain
Vergleichbare Themen
7
Antw.
Antw.
4373
Views
Views
Werte direkt nach Eingabe ermitteln
von cschmoel » 27.08.2012 11:10 • Verfasst in ABAP® für Anfänger
von cschmoel » 27.08.2012 11:10 • Verfasst in ABAP® für Anfänger
4
Antw.
Antw.
3153
Views
Views
2
Antw.
Antw.
2148
Views
Views
4
Antw.
Antw.
2110
Views
Views
SEARCH <c> FOR <str> <options> direkt im C
von the » 16.02.2005 11:56 • Verfasst in ABAP® für Anfänger
von the » 16.02.2005 11:56 • Verfasst in ABAP® für Anfänger
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.