Variablennamen mit Schrägstrich

[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.

[PascalDragon]

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

[Socke]

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.

[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.ä.

[kupferstecher]

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.

[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.

[Socke]

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.

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?

[charlytango]

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;)

[kupferstecher]

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]

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.

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).

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.

[kupferstecher]

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.

[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]

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.

[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.

[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