Wann kann man boolesche Werte in IFs direkt nutzen?
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Ups. Ich dachte, ich liege richtig mit meiner Begründung. Aber deine Erläuterung klingt sehr schlüssig. Wieder was gelernt.
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
ich sehe nicht, warum das jetzt bei Methoden anders sein sollte als bei FORMs. Was du beschreibst ist einfach schlechter Programmierstil. Und unleserliche Programme schreibe ich dir bei Bedarf sowohl in OO als auch klassisch mir FORMs und FuBas.DeathAndPain hat geschrieben: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,[...]. 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.[:::]
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.
Ich kann dem Zitat nur zustimmen in Bezug auf diese beiden Transaktionen. Aber ich muss gestehen, dass ich es lieber gesehen hätte einen Vergleich zwischen ME22N und ME22 zu machen. Und allein die Funktionserweiterung zur N-Transaktion würde die Komplexität dann schon näher aneinander bringen. Das Ganze scheint ja mal voll auf MVC umgestellt worden zu sein. Ich frage mich aber schon seit längerem, ob sich der Aufwand dafür gelohnt hat und ob es tatsächlich einen anderen View gibt, der das zugehörige Interface implementiert. Denn sonst wäre das Ganze rein akademischer Natur gewesen und hätte die Komplexitätssteigerung nicht gerechtfertigt.DeathAndPain hat geschrieben: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?"
Einerseits kann ich die Unzulänglichkeiten von Methoden gut nachvollziehen - aber der Vergleich mit FORMs stört mich ein wenig. Vergleich doch mal mit FuBa - da finden sich das Argument "Trennung von Code und Schnittstelle" genau so wieder. Allerdings war das damals noch die "Standardmodularisierung" und die Entwickler (der Sprache ABAP ) haben den Verwendern der Sprache eben das Leben noch möglichst einfach gemacht weil die wahrscheinlich Tür an Tür saßen. Heute ist jetzt "Klasse und Methode" Standard - und wenn man diese in der SE24 verwendet ( anstatt im Programm lokal zu definieren oder statt Eclipse zu verwenden ) so ist vieles für uns Entwickler gemacht worden was du anmahnst, so dass man hier auch gut entwickeln kann. Aber lokale Klassen sind halt das Stiefkind und Eclipse ist stark Java-beeinflusst und leider immer noch nicht so weit wie die klassische SE80.DeathAndPain hat geschrieben: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.[...]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.
Und zu den "akademischen" Gründen: Es sind nicht Methoden, die auseinandergerissen werden, sondern Klassen. Und ein Objekt ist zunächst mal nur eine Sammlung von Attributen ( Methoden bzw. Redefinitionen sind nur implizite Attribute die auf den zugehörige Code zeigen) , so dass man das Ganze einfach als eine weitere TYP-Definition ansehen kann - und die ist üblicherweise am Anfang eines Programms. Dass man dann auch noch Code dafür braucht ist halt das Besondere daran und ob man diesen dann völlig von der zugehörigen Schnittstelle entkoppelt (ABAP eignet sich weil die Schnittstelle fix ist abgesehen von Konstruktoren) oder näher dran lässt ( Java mit überladenen Schnittstellen ) ist einfach Geschmackssache der Sprachentwickler. Man muss es nicht lieben oder verteufeln - es ist halt so wie die Sprache designt wurde und ich halte denen einfach mal zu Gute, dass die sich Gedanken gemacht haben warum sie das so haben wollten und dass diese Gründe vielleicht weniger in der Anwendung der Sprache sondern auch durch den Interpreter oder den Kernel bedingt sein könnten.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
ralf.wenzel
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Ja, es wäre schön, wenn Fubas Aufrufe, bei denen der FB-Name als Literal übergeben wird, statisch prüfen würden angesichts der Tatsache, dass 99% aller FUBA-Aufrufe über solch Literal erfolgen.black_adept hat geschrieben: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.
Ich habe allerdings den Eindruck, dass die SAP an dieser Stelle schon anderweitig was gemacht hat. Und zwar scheinen Fubas Übergabeparameter typgerecht zu wandeln, was sie nach meiner Erinnerung früher nicht gemacht haben. Ich kann mich da durchaus täuschen, meine mich aber zu erinnern, dass Fubas das früher enger gesehen haben. Übergibt man heute einem Fuba einen Parameter mit CONV( ), dann bekommt man sogar von der Syntaxprüfung eine Warnmeldung um die Ohren gehauen, dass jener CONV( ) überflüssig sei (was sich in meinen Versuchen dann auch bestätigt hat).
Es ist auch ein Zeichen, dass Fuba-Aufrufe den CONV( ) überhaupt unterstützen. Viele ältere Befehle (etwa WRITE oder CONCATENATE) können damit leider nicht umgehen, so dass man für diese immer noch die umständlichen alten Konstrukte mit Hilfsvariablen braucht.
Für mich sind Funktionsgruppen eine vereinfachte Form (Vorstufe) von Klassen und Fubas demnach Methoden-Äquivalente, richtig. Aber wenn Du einen Fuba schreibst, dann hast Du überall - sowohl in der SE37 als auch in Eclipse - stets die vollständige Parametrisierung am Anfang. Das ist da dergestalt ausgeführt, dass dieser Kommentar automatisch vom System (nach-)gepflegt wird, sobald Du etwas an der Schnittstelle veränderst. In Eclipse ist es sogar so, dass Dich das System nicht in den entsprechenden Zeilen pfuscheln lässt, damit Du diese Kommentar-Schnittstellenbeschreibung nicht versaust (Eclipse blendet da ein paar Leerzeilen ein, in denen in der SE37 der Kommentar steht, weil in Eclipse die Parameter ja richtig zur Pflege am Anfang des Codes stehen). Das ist sehr schön gelöst; ich wünschte, so etwas gäbe es auch bei Methoden.black_adept hat geschrieben:[hinsichtlich Nachvollziehbarkeit]
ich sehe nicht, warum das jetzt bei Methoden anders sein sollte als bei FORMs. Was du beschreibst ist einfach schlechter Programmierstil. Und unleserliche Programme schreibe ich dir bei Bedarf sowohl in OO als auch klassisch mir FORMs und FuBas.
Im übrigen ist bei Fubas nicht Definition und Implementierung auseinandergerissen. Das Einzige, was man sich ergänzend noch wünschen würde, wären Fuba-lokale Formroutinen. Syntaktisch würden die natürlich geschachtelten Methodendefinitionen entsprechen, die es ja auch nicht gibt.
Wie kommst Du denn darauf? Beim Fuba habe ich alles an einem Ort und die Schnittstelle am Anfang. In Eclipse kann ich sie dort sogar pflegen und verändern, in der SE37 ist das etwas anders (aber ähnlich übersichtlich) gelöst. Ich muss nicht etwa die Schnittstelle des Fuba im Top-Include der Funktionsgruppe pflegen und seine Implementierung dann später in seinem bausteinspezifischen Include, oder was da an Blödsinn sonst noch denkbar wäre - und bei Methoden leider Realität ist.black_adept hat geschrieben:Einerseits kann ich die Unzulänglichkeiten von Methoden gut nachvollziehen - aber der Vergleich mit FORMs stört mich ein wenig. Vergleich doch mal mit FuBa - da finden sich das Argument "Trennung von Code und Schnittstelle" genau so wieder.
Die SE24 ist nicht das Schlechteste, doch stören mich darin die vielen Medienbrüche. Mann muss ständig zwischen Tastatur und Maus hin- und herspringen, Tabreiter wechseln und so. Das bremst mich massiv in meinem Arbeitsfluss aus. Bei Fubas ist das weit besser, und die Medienbrüche, die einem die SE37 noch aufnötigt, kann man sich auch noch ersparen, indem man den Fuba per Eclipse bearbeitet.black_adept hat geschrieben:Heute ist jetzt "Klasse und Methode" Standard - und wenn man diese in der SE24 verwendet ( anstatt im Programm lokal zu definieren oder statt Eclipse zu verwenden ) so ist vieles für uns Entwickler gemacht worden was du anmahnst, so dass man hier auch gut entwickeln kann.
Kann man systemglobale Klassen überhaupt per Eclipse (anstelle von SE24) bearbeiten? Wäre mal interessant.
Die SE80 habe ich schon seit jeher gehasst und arbeite auch heute noch so gut wie gar nicht damit. Wesentlicher Grund: Ihre schon immer unterirdische Performance. Von diversen Ungereimtheiten wie Endlosschleifen in darin dargestellten Hierarchiebäumen mal abgesehen. Die SE80 ist mir einfach zu langsam, um ein akzeptables Arbeitsmittel zu sein. Da kenne ich meine Transaktionen (SE38, SE37, SE51, SE43, SE93 usw.) lieber auswendig und nutze sie direkt, da bin ich schneller.black_adept hat geschrieben:Aber lokale Klassen sind halt das Stiefkind und Eclipse ist stark Java-beeinflusst und leider immer noch nicht so weit wie die klassische SE80.
Wenn hier METHOD... DEFINITION steht, am anderen Ende des Programms METHOD... IMPLEMENTATION und am Anfang des Programms am besten noch METHOD... DEFINITION DEFERRED, dann ist für mich nicht die Klasse auseinandergerissen, sondern die Methode. Die Klasse allenfalls insofern, als die Methode halt Teil der Klasse ist.black_adept hat geschrieben:Und zu den "akademischen" Gründen: Es sind nicht Methoden, die auseinandergerissen werden, sondern Klassen.
Dieses Argument kann ich zwar nachvollziehen, aber letztlich rechtfertigst Du eine Unzulänglichkeit nur mit einer anderen. Richtig wäre, wenn die TYPE-Definitionen zur Kompilierzeit ausgewertet werden würden und dann auch lageunabhängig im ganzen Programm (bzw. bei lokalen Typdefinitionen im gesamten Unterprogramm) zur Verfügung stünden. Technisch sehe ich nichts, was dagegen sprechen würde. Dass eine Typdefinition erst hinter ihrer Stellung im Code genutzt werden kann, erfüllt keinen für mich erkennbaren Nutzen, sondern ist nur ein Ärgernis. Mit dieser Einschränkung könnte man dann auch gleich aufräumen. Genau wie bei den Methoden. Die Formroutinen zeigen seit jeher, wie es geht.black_adept hat geschrieben:Und ein Objekt ist zunächst mal nur eine Sammlung von Attributen ( Methoden bzw. Redefinitionen sind nur implizite Attribute die auf den zugehörige Code zeigen) , so dass man das Ganze einfach als eine weitere TYP-Definition ansehen kann - und die ist üblicherweise am Anfang eines Programms.
Letzteres halte ich ehrlich gesagt für ausgeschlossen. Solche Deklarationen ortsunabhängig zur Kompilierzeit auszuwerten kann bei der Compilererstellung nicht das Problem sein. Dazu machen Compiler ja schon seit jeher mehrere Pässe über den Code, und bei Formroutinen funktioniert das ja auch schon seit antiken Releases.black_adept hat geschrieben:Man muss es nicht lieben oder verteufeln - es ist halt so wie die Sprache designt wurde und ich halte denen einfach mal zu Gute, dass die sich Gedanken gemacht haben warum sie das so haben wollten und dass diese Gründe vielleicht weniger in der Anwendung der Sprache sondern auch durch den Interpreter oder den Kernel bedingt sein könnten.
Gedanken werden sie sich sicherlich gemacht haben. Ich befüchte nur, dass dabei - neben von Uni-Professoren getriebenen akademischen Erwägungen - als Ziel formuliert wurde, möglichst ähnlich zu anderen Programmiersprachen anstatt möglichst effizient in der Nutzung zu sein, um Umsteigern die Hürde zu senken.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Daniel
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Selbstverständlich.DeathAndPain hat geschrieben:Kann man systemglobale Klassen überhaupt per Eclipse (anstelle von SE24) bearbeiten? Wäre mal interessant.
Vor dem Hintergrund einer immer heterogener werdenden Welt auch sehr nachvollziehbar. Ich lerne zunehmend Menschen kennen, die in X Programmiersprachen arbeiten, von denen ABAP nur eine ist. Und die typischen "Besonderheiten" von ABAP sind ein deutliches Lernhindernis für Menschen, die in ABAP nicht ihre Lebensaufgabe sehen. Stattdessen springen sie zwischen den Sprachen hin und her, das ist eine Entwicklung, wie sie sich zukünftig verstärken wird. Und nicht nur zwischen Programmiersprachen nativeSQL, R, Java, JavaScript, HTML5, ... Ich führe in letzter Zeit interessante Gespräche mit einem alten Freund, der Kommunalstatistiker ist und der R so gut beherrscht wie wir ABAP.DeathAndPain hat geschrieben:als Ziel formuliert wurde, möglichst ähnlich zu anderen Programmiersprachen .... zu sein, um Umsteigern die Hürde zu senken.
Es ist ja nicht so, dass die Vorteile von ABAP "kaputtgemacht" werden, es gibt zusätzliche Optionen.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Nein! Die ABAP-Syntax kennt zwar CLASS xyz DEFINITION [DEFERRED] oder CLASS xyz IMPLEMENTATION - aber für Methoden ist so was nicht angedacht.DeathAndPain hat geschrieben: Wenn hier METHOD... DEFINITION steht, am anderen Ende des Programms METHOD... IMPLEMENTATION und am Anfang des Programms am besten noch METHOD... DEFINITION DEFERRED, dann ist für mich nicht die Klasse auseinandergerissen, sondern die Methode. Die Klasse allenfalls insofern, als die Methode halt Teil der Klasse ist.
Bist du da auf dem Laufenden? One-Pass-Compiler gibt es schon sehr sehr lange (80er?). Ich erinnere mich zumindest noch daran, dass PASCAL-Kompilierungen immer schneller wurden bis dann endlich der 1. One-Pass-Compiler angeboten wurde (TURBO-Pascal?) und die Compilezeiten drastisch in den Keller gingen. Ich glaube mich auch daran zu erinnern, dass für One-Pass-Compiler die Sprache gewissen Regeln unterliegen muss - und ABAP scheint mir darauf ausgelegt zu sein.DeathAndPain hat geschrieben: Letzteres halte ich ehrlich gesagt für ausgeschlossen. Solche Deklarationen ortsunabhängig zur Kompilierzeit auszuwerten kann bei der Compilererstellung nicht das Problem sein. Dazu machen Compiler ja schon seit jeher mehrere Pässe über den Code, und bei Formroutinen funktioniert das ja auch schon seit antiken Releases.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
ralf.wenzel
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Daniel hat geschrieben: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.
So GANZ falsch lag ich dann doch nicht - aber ganz richtig lag auch keinerblack_adept hat geschrieben:DAS ist leider nicht der Grund.
Ich hab mal einen Bekannten bei der SAP gefragt, der mir aus den Tiefen der Entwicklungsabteilung folgende Antwort besorgt hat, die ich hier in Auszügen zitieren möchte:
Und weiter (ich hatte Bezug genommen auf die von Daniel erwähnte Tabelle):Bei der Einführung von ABAP-Objects wurde entschieden, dass im Gegensatz zu FORM und FUNCTION eine statische Prüfung durchgeführt soll. Dafür war die Implementierung neuen umfangreichen Infrastruktur notwendig. Beispielsweise gibt es im ABAP-Objects spezielle Header-Includes, die die Signatur einer Klasse (und damit der Methoden) enthalten. Außerdem wurde alle Konzepte darauf auslegt, dass die statische Typ-Prüfung überhaupt möglich ist.
Ergo: Man braucht die gesamte Funktionsgruppe, um die Signatur eines Funktionsbausteins komplett zu beschreiben (das ist ziemlich nahe an meiner Aussage).Bei FUNCTIONs ist dies nur unvollständig gegeben. Die von Ihnen erwähnte Tabelle FUPARAREF ist eine Tabelle der TA SE37. Sie dient nur dazu, um für die tabellenorientierte Pflege die Signatur eines Funktions-Bausteins abzulegen. Aus den Informationen wird der sogenannte $-Include erzeugt, der die Signatur in Quellcode-Form enthält und vom ABAP-Compiler verwendet wird. Der $-Include beschreibt aber die Signatur nicht alleine. In diesem Include können fast beliebige Referenzen in andere Coding-Teile der Funktions-Gruppe enthalten sein. Damit ist dieser zur alleinigen Beschreibung der Signatur nicht ausreichend. Damit kann er für Syntax-Prüfung außerhalb der Funktions-Gruppe nicht verwendet werden, womit die unten erwähnte Typ-Prüfung i.A. nicht durchgeführt werden kann. Zur sicheren Bestimmung der Signatur einer FUNCTION muss daher fast die gesamte Funktions-Gruppe kompiliert werden. Dies ist aus Performance-Gründen nur im Rahmen der erweiterten Programm-Prüfung möglich.
Ralf
PS: Ich habe nicht damit gerechnet, dass sich jemand die Zeit nimmt für eine derart ausführliche Antwort (den den Rahmen des hier Zitierten deutlich sprengt).
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
Solange man keinen RFC-fähigen Funktionsbaustein anlegt, können in der Schnittstelle ja auch lokal in der Funktionsgruppe definierte Datentypen verwendet werden. Wenn man die nicht vorsorglich in ein eigenes Include gepackt hat, darf sich der Aufrufer die Datentypen selbst definieren. Ganz lustig bei Strukturen bei denen sich zwischen zwei Patchständen die Felder ändern.ralf.wenzel hat geschrieben:Ergo: Man braucht die gesamte Funktionsgruppe, um die Signatur eines Funktionsbausteins komplett zu beschreiben (das ist ziemlich nahe an meiner Aussage).
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
ralf.wenzel
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Da hast Du recht, aber die Methoden sind am Ende die Leidtragenden, weil sie eben mit auseinandergerissen werden.black_adept hat geschrieben:Nein! Die ABAP-Syntax kennt zwar CLASS xyz DEFINITION [DEFERRED] oder CLASS xyz IMPLEMENTATION - aber für Methoden ist so was nicht angedacht.
Die Compilerentwicklung hatte Jahrzehnte Zeit, um zu reifen, und ich nehme nicht für mich in Anspruch, da auf dem Laufenden zu sein. Aber:Bist du da auf dem Laufenden? One-Pass-Compiler gibt es schon sehr sehr lange (80er?).
a) Wenn es mit One-Pass-Compilern möglich ist, Aufrufe von Formroutinen zu prüfen, die erst weiter unten kommen, dann sehe ich nicht, weshalb das bei Methoden nicht möglich sein sollte. Bei Formroutinen wird auch die Schnittstelle statisch geprüft, soweit die Definition das erlaubt.
b) Überleg mal, aus welcher Zeit Turbopascal stammt. Trotz der Erweiterungen, die die Programmiersprachen seitdem mitgemacht haben, OO eingeschlossen, bin ich der Überzeugung, dass die Rechendauer der Kompilierung bei einem halbwegs vernünftigen Compiler auf heutiger Hardware und mit heutiger Compilerreife kein Thema mehr sein darf.
Ich finde es ja schon mittelalterlich, dass man sich im heutigen ABAP noch über Speicherzeiger und -bereiche Gedanken machen muss. Sowas gehört für mich in die Zeit des C64; selbst in Amiga-Basic gab es das nicht mehr. Das ist ein Anspruch, den ich an eine moderne Hochsprache stelle, dass sie von solchen hardwarenahen Details abstrahiert und den Programmierer damit in Ruhe lässt.
Das sagt doch nur aus, dass man bei ABAP OO auf den Trichter gekommen ist, rechtfertigt aber nicht, weshalb man es seinerzeit bei Fubas nicht gemacht hat. und das war doch die Frage.Ralf hat geschrieben:So GANZ falsch lag ich dann doch nicht - aber ganz richtig lag auch keiner
Ich hab mal einen Bekannten bei der SAP gefragt, der mir aus den Tiefen der Entwicklungsabteilung folgende Antwort besorgt hat, die ich hier in Auszügen zitieren möchte:Bei der Einführung von ABAP-Objects wurde entschieden, dass im Gegensatz zu FORM und FUNCTION eine statische Prüfung durchgeführt soll.
Das ist mir nicht ausreichend bzw. verständlich genug erklärt. Weshalb sollten diese Referenzen die Prüfung der Schnittstelle zur Compile-Zeit verhindern? Die Schnittstelle des FuBas selbst haben wir in der FUPARAREF. Die kann man prüfen. Nur falls man feststellt, dass sich darin ein lokal definierter Datentyp befindet, muss man dessen Definition im Code suchen.Ralf hat geschrieben:Bei FUNCTIONs ist dies nur unvollständig gegeben. Die von Ihnen erwähnte Tabelle FUPARAREF ist eine Tabelle der TA SE37. Sie dient nur dazu, um für die tabellenorientierte Pflege die Signatur eines Funktions-Bausteins abzulegen. Aus den Informationen wird der sogenannte $-Include erzeugt, der die Signatur in Quellcode-Form enthält und vom ABAP-Compiler verwendet wird. Der $-Include beschreibt aber die Signatur nicht alleine. In diesem Include können fast beliebige Referenzen in andere Coding-Teile der Funktions-Gruppe enthalten sein. Damit ist dieser zur alleinigen Beschreibung der Signatur nicht ausreichend.
Davon abgesehen sind wir uns vermutlich einig, dass es (aus den von a-dead-trousers genannten Gründen) ganz schlecht ist, die Schnittstelle eines Fubas über einen Datentyp zu definieren, der lokal in der Funktionsgruppe definiert ist. Da wäre es besser gewesen, man hätte das syntaktisch verboten und dafür das Interface zur Compile-Zeit anhand der FUPARAREF geprüft.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Das ist doch erklärt worden: Weil man dafür eine umfangreiche Infrastruktur hätte entwickeln müssen in einem funktionierenden Umfeld. Das ist deutlich aufwendiger als wenn man es eh neu schreibt (wie im Zuge der OO Einführung geschehen).DeathAndPain hat geschrieben:Das sagt doch nur aus, dass man bei ABAP OO auf den Trichter gekommen ist, rechtfertigt aber nicht, weshalb man es seinerzeit bei Fubas nicht gemacht hat. und das war doch die Frage.
Eben, also ist die Schnittstelle eben nicht komplett in der Tabelle ersichtlich. Und dann musst du zumindest die Prüfung so weit erweitern, dass theoretisch alle Fälle abgedeckt werden können (sonst hast du halben Kram und keine verlässliche Prüfung). Abgesehen davon ist das ja nur EIN Beispiel, warum die Schnittstelle in der Tabelle nicht umfassend beschrieben ist.DeathAndPain hat geschrieben:Das ist mir nicht ausreichend bzw. verständlich genug erklärt. Weshalb sollten diese Referenzen die Prüfung der Schnittstelle zur Compile-Zeit verhindern? Die Schnittstelle des FuBas selbst haben wir in der FUPARAREF. Die kann man prüfen. Nur falls man feststellt, dass sich darin ein lokal definierter Datentyp befindet, muss man dessen Definition im Code suchen.
Die Referenzen verhindern die Prüfung der Schnittstelle nicht, sie machen sie nur SO zeitaufwendig, dass an eine Prüfung in der Syntaxprüfung nicht zu denken ist. Darum ging es ja.
Tja, es ist jetzt aber wie es ist. Das ist ja kein Wunschkonzert, man muss es nehmen, wie es ist und damit muss man arbeiten.DeathAndPain hat geschrieben:Davon abgesehen sind wir uns vermutlich einig, dass es (aus den von a-dead-trousers genannten Gründen) ganz schlecht ist, die Schnittstelle eines Fubas über einen Datentyp zu definieren, der lokal in der Funktionsgruppe definiert ist. Da wäre es besser gewesen, man hätte das syntaktisch verboten und dafür das Interface zur Compile-Zeit anhand der FUPARAREF geprüft.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Was für ein "funktionierendes Umfeld" soll das sein? Als die Fubas eingeführt wurden, da wurden sie eingeführt. Und da hätte man es auch gleich richtig machen können.Das ist doch erklärt worden: Weil man dafür eine umfangreiche Infrastruktur hätte entwickeln müssen in einem funktionierenden Umfeld.
Und auch später hätte man es durchaus noch tun können. Es wäre nicht der erste existierende Befehl gewesen, der nachträglich noch verbessert worden ist. Tatsächlich haben sie den CALL FUNCTION ja auch noch nachträglich verbessert, indem sie ihm die Fähigkeit gegeben haben, mit Ausdrücken umzugehen. Das finde ich da noch weniger nützlich, als es z.B. bei WRITE gewesen wäre.
Der einzige Fall, in dem das wirklich eine Rolle spielt, ist der, bei dem eine im DDIC vorhandene Typdefinition von einer lokalen verschattet und die dann für das Fuba-Interface genutzt wird. Ein Fall von Horrorprogrammierung also, die man gerne syntaktisch hätte verbieten dürfen. Dann könnte der Compiler einfach hingehen und jeden im Interface genannten Typ im DDIC suchen. Nur wenn er ihn nicht findet, müsste er dann den Fuba so weit kompilieren, dass er an die lokale Definition herankommt. Solch Fuba würde also langsamer kompilieren, was ich aber durchaus als gerechte Strafe dafür ansehen würde, dass ein Programmierer lokal definierte Typen im Fuba-Interface einsetzt.Eben, also ist die Schnittstelle eben nicht komplett in der Tabelle ersichtlich. Und dann musst du zumindest die Prüfung so weit erweitern, dass theoretisch alle Fälle abgedeckt werden können
Natürlich hätte man alternativ auch gleich meinem vorherigen Vorschlag folgen und letzteres komplett verbieten können.
Das ist sowieso richtig. Wir haben ja hier auch nicht den Anspruch, die Sprache verändern zu können, sondern tauschen uns nur darüber aus. Dazu muss auch mal ein gelegentlicher Rant gehören dürfen. Und manchmal bekommt man ja auch einen überraschenden Tipp, wie man das eine oder andere Problem lösen kann. Ich bin heute noch dankbar für die Shortcuts Strg+O bzw. Strg+L, mit denen man in Eclipse und SE38 direkt zu einer Zeilennummer springen kann.Tja, es ist jetzt aber wie es ist. Das ist ja kein Wunschkonzert, man muss es nehmen, wie es ist und damit muss man arbeiten.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Tja, warum man das vor 30 Jahren nicht gemacht hat, kann ich dir nicht sagen. Das müsste Daniel dir sagen können, der kann den Kernel nachts um drei runterbeten.DeathAndPain hat geschrieben:Was für ein "funktionierendes Umfeld" soll das sein? Als die Fubas eingeführt wurden, da wurden sie eingeführt. Und da hätte man es auch gleich richtig machen können.
Nachträglich was syntaktisch zu verbieten ist nicht einfach, weil dann funktionierende Kundenprogramme plötzlich nicht mehr laufen. Was meinst du, warum ABAP so viele Altlasten mit sich herumschleppt? Und ob das der einzige Fall ist, kannst du - mit Verlaub - nicht beurteilen.DeathAndPain hat geschrieben:Der einzige Fall, in dem das wirklich eine Rolle spielt, ist der, bei dem eine im DDIC vorhandene Typdefinition von einer lokalen verschattet und die dann für das Fuba-Interface genutzt wird. Ein Fall von Horrorprogrammierung also, die man gerne syntaktisch hätte verbieten dürfen.
Das ist kein Austausch, du regst dich über was auf, dir wird erklärt warum das technisch so ist (wofür man dann noch extra seine SAP-Kontakte spielen lässt) und du antwortest, dass du das alles viel besser gemacht hättest (bzw. die SAP, wenn sie dich gefragt hätte). Ich kann sehr gut verstehen, dass die Funktionsbaustein-Logik nicht neu erfunden werden sollte, die haben ganz andere Baustellen.DeathAndPain hat geschrieben:Das ist sowieso richtig. Wir haben ja hier auch nicht den Anspruch, die Sprache verändern zu können, sondern tauschen uns nur darüber aus.
Immerhin habe ich eine Menge gelernt in diesem Thread.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Ich kann D&P hier nur zustimmen. Die Antwort von SAP ist vielleicht inhaltlich korrekt - aber sie übertüncht nur das Problem, dass man keine Lust hatte da was zu erweiteren. Selbst wenn die Schnittstelle nicht vollständig aus der Tabelle beschrieben wird - ich schätze, dass die Anzahl der nicht überprüfbaren Parameter in der Gesamtzahl aller Parameter verschwindend ist. Und aktuell hat man das Problem, dass man den Fehler entweder erst bei der erweiterten Syntaxprüfung oder zur Laufzeit mit einem Kurzdump bemerkt. Und ehrlich gesagt - mir wäre es 1000x lieber, wenn beim Drücken auf "Prüfen" oder "Generieren" schon mal 99% der verwendeten Parameter (schnell) überprüft werden als dass man sich auf diese Aussage zurückzieht.
"Lieber gar nicht prüfen als nicht vollständig prüfen" - kommt mir irgenwie bekannt vor.....
"Lieber gar nicht prüfen als nicht vollständig prüfen" - kommt mir irgenwie bekannt vor.....
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
DeathAndPain
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Ich glaube nicht, dass das eine Lustfrage war. Ich denke, die hatten einfach andere Baustellen.black_adept hat geschrieben:Ich kann D&P hier nur zustimmen. Die Antwort von SAP ist vielleicht inhaltlich korrekt - aber sie übertüncht nur das Problem, dass man keine Lust hatte da was zu erweiteren.
Und auch wenn man natürlich kritisieren darf und soll, frag ich mich manchmal, warum die, die eh alles besser wissen, nicht selbst eine Softwarefirma gegründet haben, um dann alles besser zu machen als die SAP. Kann ja so schwer nicht sein, wie man liest.
Ich kann solche Probleme hinnehmen, weil ich weiß, wie schwierig das ist, sich bei immer neuen Aufgaben um alte Sachen zu kümmern und sie auf einem ähnlich aktuellen Stand zu halten. Das macht man erst, wenn es sich aus irgendeinem zwingenden Grund als notwendig erachtet.
Beispiel: Auch, wenn das viel einfacher wäre, würde sicher niemand auf die Idee kommen, vorhandenes Coding nach einem Releasewechsel auf 7.40 umzuschreiben, selbst wenn sich dadurch Vorteile ergäben. Und wenn mir die SAP sagt: "Bei Funktionsbausteinen war uns der Aufwand zu hoch, die ganze Infrastruktur einzuziehen wie wir es bei Klassen gemacht haben" ist das für mich eine valide Begründung. Da erwarte ich dann nicht, dass die mir ihren Terminkalender zeigen, damit ich das auch nachprüfen kann.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Von der Sache her stimmt das, aber ich behaupte, Fubas, die existierende DDIC-Typen in ihrer Schnittstelle verwenden, diese jedoch mit einer lokalen Typdefinition verschatten, sind von der Anzahl her so verschwindend, dass es durchaus zu vertreten gewesen wäre, wenn die wenigen Fälle, in denen jemand ernsthaft sowas gemacht hat, in der SPAU hochkommen und angepasst werden müssen.Nachträglich was syntaktisch zu verbieten ist nicht einfach, weil dann funktionierende Kundenprogramme plötzlich nicht mehr laufen. Was meinst du, warum ABAP so viele Altlasten mit sich herumschleppt?
Es wäre auch nicht das erste Mal, dass die SAP eine nicht abwärtskompatible Änderung durchführt. Unter Release 3.1i durften Feldnamen durchaus auch noch Umlaute enthalten. In den 4er-Releases wurde dies abgeschafft. Programme, die solche Variablennamen enthalten haben, waren plötzlich syntaktisch inkorrekt und mussten angepasst werden.
Ob das ein Zugeständnis an Unicode war oder es andere Gründe dafür gab, will ich hier gar nicht erörtern. Zweifellos waren davon aber weit mehr Kundenprogramme betroffen als von dem hier bei Fubas beschriebenen Extremfall. Vom Grundsatz her hast Du natürlich recht, dass man solche Änderungen möglichst vermeiden sollte.
Natürlich kann ich das; so komplex ist der Sachverhalt nicht. Die Schnittstelle eines FuBa ist in der Tabelle FUPARAREF definiert. Das einzige, was daran unklar sein kann, ist die Definition der dabei verwendeten Typen. Soweit diese im DDIC liegen, hat ein Compiler bei der Syntaxprüfung auch wieder kein Problem. Also bleibt nur der eine Fall, dass die Schnittstelle eine Typdefinition verwendet, die nicht im DDIC hinterlegt ist. Dann aber muss sie lokal sein, was der Compiler anhand der Abwesenheit des Typs im DDIC erkennen kann - außer im besonderen Spezialfall der Verschattung.Und ob das der einzige Fall ist, kannst du - mit Verlaub - nicht beurteilen.
Du widersprichst Dir gerade selber, denn wenn es kein Austausch wäre, sondern ich mich hier nur aufregen würde, dann hättest Du nichts gelernt.Das ist kein Austausch, du regst dich über was auf, dir wird erklärt warum das technisch so ist (wofür man dann noch extra seine SAP-Kontakte spielen lässt) und du antwortest, dass du das alles viel besser gemacht hättest (bzw. die SAP, wenn sie dich gefragt hätte). Ich kann sehr gut verstehen, dass die Funktionsbaustein-Logik nicht neu erfunden werden sollte, die haben ganz andere Baustellen.
Immerhin habe ich eine Menge gelernt in diesem Thread.
Tatsächlich ist es genau das, was ich in meiner vorhergehenden Antwort gesagt habe: ein Austausch, bei dem ich mir erlaubt habe, mal einen Rant einzustreuen ( https://www.urbandictionary.com/define.php?term=rant ). Dass Du eine Erklärung der Historie beigetrieben hast, ist sehr freundlich von Dir, was ich nicht sarkastisch, sondern durchaus ehrlich meine. Aber: bloß weil die SAP eine Erklärung abgibt, wie es zu dem Status Quo gekommen ist, heißt das nicht, dass wir alle auf die Knie fallen und ihn gut finden müssen. Auch wenn wir genau wissen, dass wir es nicht ändern können und am Ende damit leben müssen.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Ich widerspreche mir nicht, den Lerneffekt habe ich aus der Mail der SAP gezogen
Und auf die Knie fallen muss man nicht, aber man kann das einfach mal hinnehmen statt zu meckern, man hätte es ja machen können und selbst sicher so gemacht. Dafür kenne ich zu viele Programme von zu vielen Entwicklern, die auch Altlasten in sich tragen.
Ralf
Und auf die Knie fallen muss man nicht, aber man kann das einfach mal hinnehmen statt zu meckern, man hätte es ja machen können und selbst sicher so gemacht. Dafür kenne ich zu viele Programme von zu vielen Entwicklern, die auch Altlasten in sich tragen.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
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.