Führende Nullen löschen

Hallo Thomas,

ohne es auszuprobieren (gerade kein systemzugriff) ein Vorschlag:
p_var ist dabei das Feld wo der Inhalt drinsteht.
So bleiben die Zahlen an ihrer Stelle. Oder soll das ganze ganze dann linksbündig sein ?! dann kannst du evtl. SHIFT nutzen...

Grüße

Richard

Hallo Thomas,
oder ganz einfach:

lg khb

Re: Führende Nullen löschen

Manche Problemchen kommen immer wieder. Ich hatte damals keinen Systemzugriff und mein Codebeispiel ist nicht ganz korrekt. Nach 13 Jahren ;-) hier die Korrektur:

Re: Führende Nullen löschen

Ich nehme mal an, hinter MATNR steckt auch das Datenelement MATNR, welches als Domäne MATNR hat. :). Die Domäne hat die Konvertierungs-Routine MATN1 hinterlegt. Somit sollte die Konvertierung über den Fuba CONVERSION_EXIT_MATN1_OUTPUT erfolgen. Ob der Fuba das macht, was hier gewünscht ist, müsste man prüfen.
Bei der Konvertierung von 000000000000012312 werden die Nullen mit dem Fuba gelöscht.
Bei einer ALPHA-Konvertierung macht man es jedenfalls so....

Re: Führende Nullen löschen

Interessant ist, dass viele Lösungen auf eine zurückgehen. Das String-Template aus dem letzten Vorschlag verwendet die Standard-Konvertierung ALPHA aus dem vorletzten, etc.


Ralf

Re: Führende Nullen löschen

Grundsätzlich ist es nicht falsch, einen FB in eine Methode zu kapseln. Man kann eine Funktionsgruppe derart erweitern, dass man mit mehreren Instanzen arbeiten kann. Man kann sogar statische Methoden verwenden, weil die als funktionale Methoden das Coding nicht so sehr zerschneiden wie das z. B. ein Konvertierungsexit macht. Und manchmal ist ein sprechender Methodenname geeignet, seine Funktion deutlich besser zu erklären als der manchmal vermurkste Name eines FB.

Auch in diesem Falle würde ich eine Methode bauen, die z. B. „strip_leading_0“ heißen könnte.


Ralf

Re: Führende Nullen löschen

Ihr habt recht; ich war hier schon etwas sarkastisch. Wobei ich speziell in diesem Fall durchaus der Meinung bin, dass der SHIFT-Befehl nicht nur die schnellste, sondern zugleich auch für den Leser verständlichste Variante ist. Ich jedenfalls würde den SHIFT sofort verstehen, bei
aber erst mal grübeln und nachlesen müssen, was diese Syntax mir genau sagen möchte. Und wenn ich sie verstanden hätte, müsste ich mir auch noch ins Gedächtnis rufen, was der Alpha-Konvertierungsexit genau tut. Insofern fallen bei dieser Aufgabenstellung nach meiner Überzeugung Schönheit und Geschwindigkeit zusammen, so dass alles andere auf jeden Fall Overkill ist.

black_adept hat geschrieben:So weh es mir tut Ralf zustimmen zu müssen, aber ein gekapselter Aufruf der Alphakonvertierung ( in Zeiten vor den Stringtemplates ) war immer lesbarer als der explizite Aufruf des Conversionexits.

Die Option der funktionalen Methoden zählen auch zu dem, was mir an OO noch am Sympathischsten ist. Leider gilt das aber halt nur für die Aufrufstelle. Der Preis, den man dafür bezahlt, sind auseinandergerissene Definition und Implementation, was ich schon immer als rein akademisch und praxisfremd empfunden habe, da es die Lesbarkeit der Implementierung drastisch verbessert, wenn man am Kopf derselben die Parameterschnittstelle sieht, so wie bei einem Funktionsbaustein oder einer Formroutine. Wohl deswegen hat die SAP ja in der SE24 so eine Krücke gebaut mit der formularbasierten Darstellung, bei der man bei Methoden die Parameter außerhalb des Quellcodefensters sieht - für den Preis, dass dieses gewaltig schrumpft und man in einem Mäusekino programmiert. Bei Eclipse sieht man die Parameter gar nicht (ich habe mir zur Angewohnheit gemacht, sie mir als Kommentar aus der Definition zu kopieren und am Anfang der Implementierung einzufügen. Aber wehe, man ergänzt oder ändert rasch mal einen Parameter - dann passt der Kommentar nicht mehr).

Wenn man dem Codefluss folgt, sieht man die Aufrufstellen, und die sind bei Methoden - selbst bei nichtfunktionalen - in der Tat bedeutend schöner als bei Funktionsbausteinen oder Formroutinen. Ich finde es nur halr so schade, dass man immer so einen Riesenaufwand treiben muss, um eine neue Methode einzuführen. SE24 mag ich gar nicht wegen des Inputmedienbruchs - ich kann dort nicht alles mit der Tastatur machen, sondern muss ständig zur Maus greifen. In Eclipse sind die Bestandteile der Methoden über den Code verstreut. Seufz. Formroutinen kann man aufrufen, egal wo im Code sie stehen, sogar DDIC-globale TYPE-POOLS sind mittlerweile ohne jede Deklaration im Code überall verfügbar. Nur bei den Methoden, die das Modernste repräsentieren sollen, gibt es die unsinnige Einschränkung, dass die Methode nur gefunden wird, wenn ihre Definition vor der Aufrufstelle liegt. Noch nicht einmal mit einem DEFINITION DEFERRED ist dies wirksam zu umgehen.

Ralf hat geschrieben:Man kann eine Funktionsgruppe derart erweitern, dass man mit mehreren Instanzen arbeiten kann.

Du bist beinahe der Einzige, dem ich zutraue, mit Instanzen vernünftig umzugehen. Ich bin von genug Entwicklern und Beratern umgeben und sehe deren Code. Wenn da Instanzobjekte zum Einsatz kommen, dann nahezu immer in der Form, dass nur ein einziges Objekt erzeugt und damit dann gearbeitet wird. Dann aber ist die Instanz nur ein Wasserkopf, und eine statische Klasse (wie ich sie praktisch nur erstelle) ist die bessere Wahl. Von Vererbung will ich gar nicht erst anfangen. Ein schönes Konzept, aber benutzen tut es außer der SAP und Dir niemand.

Damit einhergehend sind Attribute von Objekten in der Theorie nett und schön, um Objektzustände zu setzen. Die Attribute, die ich freilich real im Code anderer Entwickler sehe, sind von der Art und Weise, wie sie genutzt werden, aber nichts anderes als herkömmliche globale Variablen, mit denen die Kapselung umgangen und die Programmstrukturierung durchbrochen wird, so dass im Code Werte vom Himmel fallen und man nicht weiß, wo sie herkommen. Attribute halte ich für den Hauptgrund, weshalb man fremden objektorientierten Code in aller Regel so viel schlechter verstehen und mit dem Debugger analysieren kann als prozeduralen. Bei prozeduralem Code sind globale Variablen auch möglich, aber gefühlt würde ich sagen, dass die Schlamperei mit globalen Variablen anstelle ordentlicher Übergabeparameter bei OO noch verbreiteter bzw. größer ist - vermutlich deshalb, weil man den Entwicklern, die das machen, das Alibi quasi frei Haus liefert, nämlich dass es ja keine verwerflichen globalen Variablen sind, sondern moderne "Attribute". Das Ziel, mit dem OO mal angetreten ist, nämlich die Entwickler zu einer besseren Kapselung zu drängen, ist damit jedenfalls gründlich verfehlt worden; der Code ist schlechter lesbar als der alte.

Was ich durchaus schade finde, denn die Ideen und Konzepte in OO sind ja eigentlich durchaus gut, etwa dass man Unterroutinen als privat deklarieren kann, die schöneren Aufrufe oder auch funktionale Methoden. Nur die Praxis hält sich halt nicht an das, was die Akademiker sich da ausgedacht haben - und die sind offenbar so praxisfern, dass sie das nicht sehen und darauf mit Anpassungen in der Sprache reagieren. Wie man da rangehen könnte, müsste man mal überlegen. Aus meiner Sicht könnte ein möglicher Weg darin bestehen, dass Attribute gar keine Felder sind, sondern "Speicherslots" des Objektes, in denen man per SET ATTRIBUTE attributname = feld bzw. GET ATTRIBUTE attributname INTO feld Zustandswerte ablegen und wieder zurückholen kann. Das hat zwar etwas von einem IMPORT FROM MEMORY, aber das Ziel, das man in meinen Augen damit erreichen würde, wäre, dass die Bequemlichkeit der globalen Variablen dahin wäre. Wenn die Attribute nicht einfach überall in der Klasse als normale Feldwerte präsent sind, sondern man jedesmal den Aufwand treiben müsste, sich den Wert mit o.g. Befehlen zu beschaffen bzw. darin abzuspeichern, dann würden vermutlich so einige darüber nachdenken, die Werte stattdessen doch lieber als Parameter durchzureichen, womit eine ordentliche Kapselung sich quasi von alleine ergeben würde. Aus Faulheitssicht hätten Attribute dann keinen Vorteil mehr. Zudem könnte man sich damit sicherlich auch die eine oder andere SET- und GET-Methode sparen, da diese Befehle das ja gewissermaßen ersetzen würden.

Nur so eine Idee von mir. Wird eh keiner umsetzen. 😥