
Und FORM-Routinen gegenüber Methoden, weil bei FORM-Routinen das Interface gut sichtbar über der Codedefinition steht und nicht am anderen Ende des Programms. Außerdem werden FORM-Routinen gefunden, egal wo sie im Programmcode stehen und nicht nur, wenn ihre Definition hinter der Aufrufstelle steht (wodurch man sich bei FORM-Routinen auch Unsinn wie DEFINITION DEFERRED-Anweisungen sparen kann).black_adept hat geschrieben:Davon abgesehen haben statische Methoden Vorteile gegenüber FORM-Routinen wegen ihres flexibleren Interfaces.
Das für mich mindestens ebenso gewichtige Argument ist, dass man sich damit die Definition einer separaten Workarea-Variable spart, sondern ein Feldsymbol nutzen kann, das (bei mir) immer genauso wie die zugehörige interne Tabelle heißt, mit dieser aufgrund der umschließenden Feldsymbolwinkel aber nicht verwechselt werden kann. Eine Workarea muss, wenn man nicht mit Kopfzeilen arbeiten möchte, WA_tabellenname heißen, was sperrig und hässlich ist. Viele nehmen stattdessen sogar LV_tabellenname, wodurch man dem Feld nicht mal mehr ansieht, welchem Zweck es dient. <tabellenname> hingegen ist schön prägnant (wenngleich etwas blöd zu tippen).black_adept hat geschrieben:Aber ich gebe Ralf insofern recht, dass es im Allgemeinen wenig andere Gründe gibt, so dass die Performance als dann einziges Kriterium dann doch zur Verwendeung des Feldsymbols führt.
Durchaus. Wenn jemand erst die Grundlagen lernt, dann muss er erst mal begreifen, wie man mit Feldern, internen Tabelle und Datenbanktabellen hantiert. An der Stelle schon mit Zeigern auf Feldwerte im Hauptspeicher zu kommen, ist verfrüht und Overkill.Ralf hat geschrieben:Überrollen mit einem Wort wie „Feldsymbol“???
Ich nutze auch immer Hibernate, wenn ich den Akku meines Notebooks schonen möchte.msfox hat geschrieben:Ich hab das mal beim Kunden mit Hibernate gemacht.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Looper

Bei dir scheinen Variablen via HN definiert zu sein ( wa_..., lv_... ) - aber warum darf dann ( außer im Ausnahmefall Tabelle von Tabellen ) ein Feldsymbol genau so heißen wie eine zugehörige interne Tabelle ( gt_... lt_..., o.ä.)? Ich finde nicht, dass <lt_tabellenname> eine sehr gut gewählter Name ist.DeathAndPain hat geschrieben:Das für mich mindestens ebenso gewichtige Argument ist, dass man sich damit die Definition einer separaten Workarea-Variable spart, sondern ein Feldsymbol nutzen kann, das (bei mir) immer genauso wie die zugehörige interne Tabelle heißt, mit dieser aufgrund der umschließenden Feldsymbolwinkel aber nicht verwechselt werden kann. Eine Workarea muss, wenn man nicht mit Kopfzeilen arbeiten möchte, WA_tabellenname heißen, was sperrig und hässlich ist. Viele nehmen stattdessen sogar LV_tabellenname, wodurch man dem Feld nicht mal mehr ansieht, welchem Zweck es dient. <tabellenname> hingegen ist schön prägnant (wenngleich etwas blöd zu tippen).


Du meinst wohl result = kein_input=>kein_loesungsbeispiel( ). Dann bleiben wir wenigstens bei statischen Methoden und der Kreis zur Threaderöffnung ist geschloßenralf.wenzel hat geschrieben:Tja, kein Input => kein Lösungsbeispiel....
nickname8 hat geschrieben:Du meinst wohl result = kein_input=>kein_loesungsbeispiel( ). Dann bleiben wir wenigstens bei statischen Methoden und der Kreis zur Threaderöffnung ist geschloßenralf.wenzel hat geschrieben:Tja, kein Input => kein Lösungsbeispiel....
Code: Alles auswählen.
TRY.
lo_loesung = lo_abapforum->get_loesung_instance( io_input = lo_input ).
lo_loesung->apply( ).
CATCH zcx_no_input INTO lo_error.
lv_message = lo_error->get_text( ).
MESSAGE lv_message TYPE 'I'.
ENDTRY.
Nein. An der Stelle habe ich es schon immer mit Ralf gehalten (schon bevor ich ihn überhaupt kannteblack_adept hat geschrieben:Bei dir scheinen Variablen via HN definiert zu sein ( wa_..., lv_... )
Parameter ==> Selektionsbild ==> Dynpro ==> keine Blümchen und kein UI5 ==> die User wollen das nicht ==> wird ab 2025 nicht mehr unterstützt ==> Weiterentwicklung von Zombies überflüssigDeathAndPain hat geschrieben:(oder auch nicht, weil ich zuweilen gerne noch mehr hätte. Sicher ist aber, dass 8 Zeichen Maximallänge für Report-Parameter in der heutigen Zeit eine Frechheit sind und es der SAP problemlos möglich wäre, dieses Limit voll abwärtskompatibel aufzubohren. Aber das ist auch wieder ein anderes Thema).
Schon im Jahre 2001 galt die Regel, dass Variablennamen 30 Zeichen lang sein durften und Parameternamen nur 8 Zeichen. Schon damals war das eine sinnlose und unnötige Einschränkung. Es wäre also reichlich Zeit gewesen, es zu korrigieren, auch als das SAPGui noch der letzte Schrei war.Parameter ==> Selektionsbild ==> Dynpro ==> keine Blümchen und kein UI5 ==> die User wollen das nicht
Das warten wir mal ab. Totgesagte leben länger. Am heutigen Tag ist das neue SAPGui 7.60 erschienen! Und wenn Du den Verlautbarungen der SAP aus dem ersten Jahrzehnt dieses Jahrtausend Glauben geschenkt hättest, dann hätten wir schon heute längst kein SAPGui mehr.wird ab 2025 nicht mehr unterstützt
Der Aufwand ist größer als du wahrscheinlich im 1. Moment wahrnimmst. Denn das Problem ist das Selektionsbildgenerierungsprogramm welches diverse andere Namen generiert ( z.B. die Namen der Screenelemente für die Textbezeichner wenn du dir den generierten Dynpro 1000 anschaust ) und die Millionen alter Programme, die darauf vertrauen, dass das alles so ist wie aktuell definiert.DeathAndPain hat geschrieben:Ist ja auch immer eine Frage, von wieviel Aufwand wie reden. Wenn ich jetzt sagen würde, macht Dynpros voll objektorientiert usw., dann wäre das richtig ein Projekt, bei dem man darüber nachdenken könnte, ob sich das lohnt. Aber den Kernel zu befähigen, beim Variablennamen von Parametern mehr als acht Zeichen zu schlucken - how hard can it be?!?