Variablennamen mit Schrägstrich

Für Fragen zur Programmiersprache auf welcher Lazarus aufbaut
Socke
Lazarusforum e. V.
Beiträge: 3158
Registriert: Di 22. Jul 2008, 19:27
OS, Lazarus, FPC: Lazarus: SVN; FPC: svn; Win 10/Linux/Raspbian/openSUSE
CPU-Target: 32bit x86 armhf
Wohnort: Köln
Kontaktdaten:

Variablennamen mit Schrägstrich

Beitrag von Socke »

Hallo zusammen,

ich versuche mich gerade wieder an der Integration von Pascal mit SAP-ABAP.
Dort ist der Schrägstrich "/" ganz normaler Bestandteil eines Typ- oder Variablennamens und identifiziert hier Namensräume.

Ein Beispiel aus dem Namensraum /BODS/:
Die Tabelle /BODS/BODS hat ein Feld /BODS/NAME vom Datentyp /BODS/NAME.

Wie übersetzt man dies in einfach verständliche Pascal-Bindings? Typdeklarationen könnte man über Unit-Namespaces realisieren:
Der Typ NAME in der Unit BODS ist ein anderer Datentyp als in einer anderen Unit.

Aber wie geht man hier mit Variablennamen um? In Pascal kann ich nicht mytable./BODS/NAME schreiben um das Feld zu identifizieren.
Einfache Ersetzungen z.B. mit _ verbieten sich m.E., da _BODS_NAME ein ebenso gültiger Name ist, aber eben ein ganz anderer Datentyp/Feldname etc. sein kann.
Die Alternative wäre eine komplett dynamische Programmierung, die ist aber immer sehr schwer lesbar.
MfG Socke
Ein Gedicht braucht keinen Reim//Ich pack’ hier trotzdem einen rein

PascalDragon
Beiträge: 825
Registriert: Mi 3. Jun 2020, 07:18
OS, Lazarus, FPC: L 2.0.8, FPC Trunk, OS Win/Linux
CPU-Target: Aarch64 bis Z80 ;)
Wohnort: München

Re: Variablennamen mit Schrägstrich

Beitrag von PascalDragon »

Wie lösen das denn andere Sprachen wie C, C++, C# oder Java, die alle das gleiche Problem haben?
FPC Compiler Entwickler

Socke
Lazarusforum e. V.
Beiträge: 3158
Registriert: Di 22. Jul 2008, 19:27
OS, Lazarus, FPC: Lazarus: SVN; FPC: svn; Win 10/Linux/Raspbian/openSUSE
CPU-Target: 32bit x86 armhf
Wohnort: Köln
Kontaktdaten:

Re: Variablennamen mit Schrägstrich

Beitrag von Socke »

PascalDragon hat geschrieben:
Mo 25. Jan 2021, 13:53
Wie lösen das denn andere Sprachen wie C, C++, C# oder Java, die alle das gleiche Problem haben?
Soweit ich herausfinden konnte, nutzt man hier die dynamische Adressierung über Strings. Ich würde aber gerne darüber hinausgehen und mir für bestimmte Fälle aus den vorhandenen Informationen im Server passende Schnittstellendefinitionen generieren.
MfG Socke
Ein Gedicht braucht keinen Reim//Ich pack’ hier trotzdem einen rein

Benutzeravatar
Aidex
Beiträge: 60
Registriert: Do 24. Sep 2020, 07:02
OS, Lazarus, FPC: Win10 64bit, Laz v2.0.10
CPU-Target: AMD64

Re: Variablennamen mit Schrägstrich

Beitrag von Aidex »

Du könntest die Variablen einer Ebene als Record oder Klasse zusammenfassen.
Eine höhere Ebene könnte wiederum ein Record oder Klasse sein, die die untergeordnete Ebene als Record oder Objekt enthält.
Dann hättest du einen Zugriff über die Schreibweise z.B. BODS2.BODS1.NAME o.ä.

Benutzeravatar
kupferstecher
Beiträge: 418
Registriert: Do 17. Nov 2016, 11:52

Re: Variablennamen mit Schrägstrich

Beitrag von kupferstecher »

Socke hat geschrieben:
Mo 25. Jan 2021, 11:38
Einfache Ersetzungen z.B. mit _ verbieten sich m.E., da _BODS_NAME ein ebenso gültiger Name ist, aber eben ein ganz anderer Datentyp/Feldname etc. sein kann.
Das ist doch ein aehnliches Problem wie bei Pascalstrings, die Hochkommata enthalten. Genauso kannst du, wenn du dich fuer die Unterstrichersetzung entscheidest, urspruengliche Unterstriche einfach verdoppeln. Wenns auch mehrere Schraegstriche hintereinander geben kann, kannst du den Unterstrich als Escape-Zeichen nutzen und einen Code dahintersetzen. _s = / und _u = _

Aber vielleicht hab ich das Problem auch falsch verstanden. :D

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Variablennamen mit Schrägstrich

Beitrag von af0815 »

Es wird nur mit einem Mix mit Typen als Prefix und Ersetzen des Schrägstrichs durch gültige Zeihen sein.

Ich bin auf eine ähnlich Problematik bei der Analyse/Einarbeitung von tiOPF gestossen. Besonders bei einem Tool was Schnittstellenunits erstellt.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Socke
Lazarusforum e. V.
Beiträge: 3158
Registriert: Di 22. Jul 2008, 19:27
OS, Lazarus, FPC: Lazarus: SVN; FPC: svn; Win 10/Linux/Raspbian/openSUSE
CPU-Target: 32bit x86 armhf
Wohnort: Köln
Kontaktdaten:

Re: Variablennamen mit Schrägstrich

Beitrag von Socke »

kupferstecher hat geschrieben:
Mo 25. Jan 2021, 22:45
Wenns auch mehrere Schraegstriche hintereinander geben kann, kannst du den Unterstrich als Escape-Zeichen nutzen und einen Code dahintersetzen. _s = / und _u = _
Die Schrägstriche kommen entweder zweimal oder gar nicht vor. Sie sind tatsächlich nur dazu vorgesehen, den Namensraum zu kennzeichnen. Insofern gehören sie selbst nicht zum Typnamen sondern zum Namensraum.
Bsp: Beim Datentyp /BODS/NAME ist "/BODS/" der Namensraum.
af0815 hat geschrieben:
Di 26. Jan 2021, 08:01
Ich bin auf eine ähnlich Problematik bei der Analyse/Einarbeitung von tiOPF gestossen. Besonders bei einem Tool was Schnittstellenunits erstellt.
Das ist der identische Anwendungsbereich, nur für eine andere Anwendung. Kannst du dich noch daran erinnern, wie du hier vorgegangen bist?
MfG Socke
Ein Gedicht braucht keinen Reim//Ich pack’ hier trotzdem einen rein

charlytango
Beiträge: 843
Registriert: Sa 12. Sep 2015, 12:10
OS, Lazarus, FPC: Laz stable (2.2.6, 3.x)
CPU-Target: Win 32/64, Linux64
Wohnort: Wien

Re: Variablennamen mit Schrägstrich

Beitrag von charlytango »

Socke hat geschrieben:
Mo 25. Jan 2021, 11:38
Einfache Ersetzungen z.B. mit _ verbieten sich m.E., da _BODS_NAME ein ebenso gültiger Name ist, aber eben ein ganz anderer Datentyp/Feldname etc. sein kann.
Möglicherweise hab ich da etwas komplett falsch verstanden, aber wie wäre es denn ein Trennzeichen zu verwenden das praktisch nie in solchen Kontexten vorkommt? (und vor der ersten Ersetzung checken ob es nicht doch drin ist um dann auf ein weiteres auszuweichen)

//mögliche Trennzeichen
CT1 = #185; //¹
CT2 = #178; //²
CT3 = #179; //³
CT4 = #155; //ø
CT5 = #166; //¦
CT5 = #172; //¬
CT6 = #177; //±

aber vielleicht sehe ich den Wald vor lauter Bäumen nicht und liege komplett falsch;)

Benutzeravatar
kupferstecher
Beiträge: 418
Registriert: Do 17. Nov 2016, 11:52

Re: Variablennamen mit Schrägstrich

Beitrag von kupferstecher »

Socke hat geschrieben:
Di 26. Jan 2021, 10:56
Die Schrägstriche kommen entweder zweimal oder gar nicht vor. Sie sind tatsächlich nur dazu vorgesehen, den Namensraum zu kennzeichnen. Insofern gehören sie selbst nicht zum Typnamen sondern zum Namensraum.
Bsp: Beim Datentyp /BODS/NAME ist "/BODS/" der Namensraum.
Im Grunde ist das ja dann der Punkt in Pascal, nur dass es keinen vorangestellten Punkt gibt. Vielleicht dann einfach was davorsetzen, das erwartungsgemäß nicht als Variable vorkommt also /BODS/ wird zu NAMESPACE_Bods, der Aufruf zu NAMESPACE_Bods.Name
Die Gefahr, dass es mal doch nicht hinhaut bleibt aber.

Gibt es keine verschachtelten Namensräume in ABAB? Dann würde die Lösung über UNIT-Namen ja nicht mehr funktionieren.

Socke
Lazarusforum e. V.
Beiträge: 3158
Registriert: Di 22. Jul 2008, 19:27
OS, Lazarus, FPC: Lazarus: SVN; FPC: svn; Win 10/Linux/Raspbian/openSUSE
CPU-Target: 32bit x86 armhf
Wohnort: Köln
Kontaktdaten:

Re: Variablennamen mit Schrägstrich

Beitrag von Socke »

charlytango hat geschrieben:
Di 26. Jan 2021, 12:19
Möglicherweise hab ich da etwas komplett falsch verstanden, aber wie wäre es denn ein Trennzeichen zu verwenden das praktisch nie in solchen Kontexten vorkommt? (und vor der ersten Ersetzung checken ob es nicht doch drin ist um dann auf ein weiteres auszuweichen)
Die "Trennzeichen" müssen für Pascal-Identifier (Variablennamen, Typnamen) geeignet sein. Hier ist nur A-Za-z0-9 erlaubt.

kupferstecher hat geschrieben:
Di 26. Jan 2021, 12:23
Im Grunde ist das ja dann der Punkt in Pascal, nur dass es keinen vorangestellten Punkt gibt. Vielleicht dann einfach was davorsetzen, das erwartungsgemäß nicht als Variable vorkommt also /BODS/ wird zu NAMESPACE_Bods, der Aufruf zu NAMESPACE_Bods.Name
Die Gefahr, dass es mal doch nicht hinhaut bleibt aber.
Bei Datentypen finde ich die Deklaration in Namespace-Units ganz interessant. Bei Records oder Strukturelementen geht das leider nicht. Records in Records zur Abbildung der Namespaces sind leider nicht möglich, da dann die Reihenfolge nicht mehr beachtet werden kann (zwingde Voraussetzung).
kupferstecher hat geschrieben:
Di 26. Jan 2021, 12:23
Gibt es keine verschachtelten Namensräume in ABAB? Dann würde die Lösung über UNIT-Namen ja nicht mehr funktionieren.
Nein. Die Namensräme haben tatsächlich nur diese einfache Struktur. Hier sind maximal 10 Zeichen inkl. öffnendem und schließendem Schrägstrich vorgesehen.
Nur weil Pascal verschachtelte Namensräume unterstützt, muss man sie ja nicht zwingend nutzen.
MfG Socke
Ein Gedicht braucht keinen Reim//Ich pack’ hier trotzdem einen rein

Benutzeravatar
kupferstecher
Beiträge: 418
Registriert: Do 17. Nov 2016, 11:52

Re: Variablennamen mit Schrägstrich

Beitrag von kupferstecher »

Socke hat geschrieben:
Di 26. Jan 2021, 13:31
Nur weil Pascal verschachtelte Namensräume unterstützt, muss man sie ja nicht zwingend nutzen.
Meine Überlegung, die ich dann aber nicht geschrieben habe, war dahingehend, dass man den ersten Schrägstrich als eine Ebene betrachtet und alle Namespaces darin sammelt. Also statt /BODS/NAME hätte man in Pascal dann ROOT.BODS.NAME. In Pascal wäre das aber dann eine doppelte Verschachtelung und das funktioniert mit den Units als Namespace so ja nicht. Wenns aber sowieso keine tiefere Verschachtelung gibt, würde ich wohl mit einfacher Ersetzung arbeiten.

Benutzeravatar
Aidex
Beiträge: 60
Registriert: Do 24. Sep 2020, 07:02
OS, Lazarus, FPC: Win10 64bit, Laz v2.0.10
CPU-Target: AMD64

Re: Variablennamen mit Schrägstrich

Beitrag von Aidex »

Socke, was meinst du damit, dass bei Records oder Klassenobjekten die Reihenfolge nicht beachtet werden kann?
Ich würde einfach verschachtelte Klassen nehmen. Mittels "property" ließen sich beim Lesen/Setzen doch sogar Funktionen auslösen,
wie das bedarfsweise Erzeugen unterer Ebenen, oder das Lesen aus oder Schreiben in die DB.

Socke
Lazarusforum e. V.
Beiträge: 3158
Registriert: Di 22. Jul 2008, 19:27
OS, Lazarus, FPC: Lazarus: SVN; FPC: svn; Win 10/Linux/Raspbian/openSUSE
CPU-Target: 32bit x86 armhf
Wohnort: Köln
Kontaktdaten:

Re: Variablennamen mit Schrägstrich

Beitrag von Socke »

Aidex hat geschrieben:
Mi 27. Jan 2021, 02:58
Socke, was meinst du damit, dass bei Records oder Klassenobjekten die Reihenfolge nicht beachtet werden kann?
Ich habe dazu mal ein Beispiel herausgesucht, und frei nach Pascal übersetzt. Dazu ein paar Hintergrundinformationen:
  • Die Struktur E1MARAM dient dem Austausch von Material/Artikelstammdaten; Was die konkreten Felder hier bedeuten, kann ich aber nicht sagen.
  • In dem konkreten Beispiel wird tatsächlich nicht auf vordefinierte Datentypen referenziert sondern die Länge jedes einzelnen Feldes direkte angegeben.
  • Da die Datenstruktur dem Austausch dient, ist es vorgesehen, eine UCS-2-Zeichenkette von 1930 Bytes direkt in die Struktur hineinzukopieren und somit die Felder zu befüllen. Damit fallen Klassen weg oder benötigen einen vergleichsweise aufwändigen Kopiermethode (1 move vs. 123 moves zzgl. Adressierung).
  • So einen Record kann ich dann wunderbar in eine Datei schreiben und im SAP-System wieder einlesen.

Code: Alles auswählen

type
  E1MARAM = record
    // 113 führende Felder
    NSNID: array[0..8] of UnicodeChar;
    WEORA: array[0..0] of UnicodeChar;
    /CWM/TOLGR: array[0..8] of UnicodeChar;
    /CWM/TARA: array[0..0] of UnicodeChar;
    /CWM/TARUM: array[0..2] of UnicodeChar;
    // 5 weitere Felder
  end;
Ein typischer Zugriff wäre also:

Code: Alles auswählen

var
  SourceBuffer: UnicodeString;
  wa_e1maram: E1MARAM;
begin
  if Length(SourceBuffer) < SizeOf(wa_e1maram) then exit;
  Move(SourceBuffer[1], wa_e1maram, SizeOf(wa_e1maram));
  WriteLn('NSNID: ', wa_e1maram.NSNID);
  WriteLn('/CWM/TOLGR: ', wa_e1maram./CWM/TOLGR);
end.
Ist jetzt an anderer Stelle ebenfalls ein Feld z.B. /CWM/ABC definiert, muss der Zugriff über die Syntax wa_e1maram.CWM.ABC an ganz anderer Stelle erfolgen als wa_e1maram.CWM.TARA.
Weiterhin wäre es ein Problem, käme jemand auf die Idee ein Feld "CWM" zu nennen und darin ein Struktur mit einem Feld "TOLGR" zu definieren.

Code: Alles auswählen

// unwahrscheinlich aber möglich
type
  MyCWMRecord = record
    TOLGR: array[0..5] of UnicodeChar;
  end;
  MyMARAMRecord = record
    CWM: MyCWMRecord;
    /CWM/TOLGR: array[0..8] of UnicodeChar;
  end;
Ich habe nie behauptet, dass ABAP eine einfache Sprache sei, aber manchmal muss man nehmen, was man hat.
MfG Socke
Ein Gedicht braucht keinen Reim//Ich pack’ hier trotzdem einen rein

Benutzeravatar
Aidex
Beiträge: 60
Registriert: Do 24. Sep 2020, 07:02
OS, Lazarus, FPC: Win10 64bit, Laz v2.0.10
CPU-Target: AMD64

Re: Variablennamen mit Schrägstrich

Beitrag von Aidex »

Moin!
Ich ahnte nicht, dass es sich um eine starre Datenaustausch-Struktur handelt.
Wenn darin mehrere CWM-Unter-Elemente an mehreren Stellen verteilt sind, geht das es mit untergeordneten Records wohl wirklich nicht.

Meine Idee wäre gewesen:

Code: Alles auswählen

type
  TCWM = record
    TOLGR: array[0..8] of UnicodeChar;
    TARA: array[0..0] of UnicodeChar;
    TARUM: array[0..2] of UnicodeChar;
  end;
 
  E1MARAM = record
    NSNID: array[0..8] of UnicodeChar;
    WEORA: array[0..0] of UnicodeChar;
    CWM: TCWM;
  end;

WriteLn('/CWM/TOLGR: ', wa_e1maram.CWM.TOLGR); 
Der Zugriff über CWM.TOLGR wäre dann ja so nah wie möglich an der ABAP-Schreibweise.

Und evtl. mit "packed record" arbeiten, damit der Compiler nicht einzelne Elemente auf gerade Adressen optimiert.

Benutzeravatar
kupferstecher
Beiträge: 418
Registriert: Do 17. Nov 2016, 11:52

Re: Variablennamen mit Schrägstrich

Beitrag von kupferstecher »

Spricht eigentlich was dagegen den Namensraum ganz wegzulassen und einfach in den Bezeichnern als Präfixe unterzubringen? Das Problem der Doppeldeutigkeit bliebe zwar, aber man müsste sich um Verschachtelungen keine Gedanken mehr machen.

Also bspw.
eine Variable /BODS/NAME würde zu BODS_NAME

Wenn man dann noch mit Ersetzungen arbeitet, gibt es auch keine Doppeldeutigkeiten mehr und es scheint mir noch einigermaßen lesbar:
eine Variable /BODS/NAME würde zu BODS__NAME
eine Variable BODS_NAME zu BODS_uNAME

Antworten