[Allegro] HFM : Neue Lösung, a99-Prototyp zum Testen

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

>                                                              2014-06-23
> HFM : Neue Lösung
> -----------------
....
> 
> Hiermit wird eine Lösung vorgelegt, die zunächst mehr oder weniger
> prototypisch in a99 umgesetzt wurde, also realistisch ist.

das ist ja wunderbar!


> Zu den Details der Lösung:
> (Am Ende unter ABER stehen drei noch nicht klappende Sachen)
> 
> o  Die bisher möglichen Mehrfachfeld-Kennungen bleiben voll erhalten,
>    d.h. keine Änderungen bestehender Daten werden fällig.
> 
> o  Anwendungen arbeiten mit den neuen Programmen unbetroffen weiter,
>    also auch keine Änderungen nötig in Parametern, FLEXen und Jobs.
> 
> o  Neu hinzu kommt eine mehrstellige Mehrfachkennung aus Ziffern, die
>    wie folgt aussieht und auch in Altanwendungen ohne neue Vorkehrungen
>    sofort anwendbar ist, und zwar bei jeder CFG ohne Änderung (!):
>            #nn.zzz   (z.B. $a.cfg)
>      bzw.  #nnn.zzz  (z.B. $n.cfg, $u.cfg)
>      bzw.  #nnnn.zzz (z.B. $p.cfg)
>    mit beliebigen Ziffern z, und zwar auch mehr als 3
>    (Max. 5 werden empfohlen; mehr sind möglich - aber sinnvoll?)
>    Nur Ziffern, also auch keine Dezimalzahlen! Die erste Nichtziffer
>    ist dann das erste Zeichen des Feldinhalts.
>    Dafür wird der neue Terminus  HFM-Feld  eingeführt.

D.h. die theoretisch erlaubte, aber praktisch bislang extrem
problematische Mehrfachkennung "." (die ja analog "~" simultan eine
Steuerbedeutung hat, daher "problematisch") wird fuer den
Erweiterungsmechanismus umgenutzt: Hoechst elegant!


> o  Ältere Programme können damit nicht umgehen, sie lassen beim
>    Einlesen eines derartigen Satzes nur das letzte Feld mit dem .
>    übrig!

[Wir sollten bei Gelegenheit ueber einen Mechanismus nachdenken,
der "alte" Programme zum Ausstieg zwingt, wenn eine Datenbank
ein Feature ~nutzt~, das definitiv zu neu ist]


> o  Achtung: Zahlen nicht mit führenden Nullen schreiben, das ist
>    sinnlos! Wenn man das tut, werden die weggenommen.
> 
> o  Die Zahlen müssen nicht lückenlos aufeinander folgen.
>    Daher könnte man Nummern auch mit einer Semantik ausstatten.

Bitte nicht!

Vielmehr sollte angekuendigt werden, dass in zukuenftigen Versionen
evtl. "Einfuege"-Funktionen angeboten werden koennten, die dann natuerlich
zu einer teilweisen Umnummerierung fuehren.


o  Mit  var #nnn~  erhält man in FLEX das letzte der Mehrfachfelder
   des Feldes #nnn - wie schon bisher

Mit oder ohne Nummer?

In der Exportsprache ist es ein unglaublicher Akt, das letzte vergebene
Fortsetzungszeichen zu ermitteln, in Flex ging es mittels

_nnn~

Ist es moeglich, genauer zu klaeren, ob ".xxx" eher zur Feldbezeichnung
gehoert, an die man nur mit "_" statt "#" herankommt, oder (zumindest
teilweise) als Feldinhalt gelten soll, der auch mit "#" sichtbar ist?



> o  Für die #u-Variablen gibt es keine Änderung, d.h. man kann nicht
>    #uxy.1 und #uxy.123 usw. verwenden. Das macht, denken wir,
>    nichts aus, denn es sind ja nur temporäre Variablen, und in
>    FLEXen verwendet man eh lieber $- oder &-Variablen, die anderen
>    Gesetzen folgen.

Ja. Mir Unlieb, aber leider erforderlich ist die Nutzung von #uY~ und
#uZ~ fuer Flips. Dafuer laesst sich aber mittelfristig vielleicht
ein alternativer Mechanismus einfuehren, der ohne das simultane
automatische Hochzaehlen von #u-Variablen auskommt. Ich sehe jedenfalls
auch keinen Bedarf fuer #uxy.nnn


> ABER:
> 
> -  Noch nicht funktionabel: Ein HFM-Feld in der Kategorieliste der
>    Parameter direkt ansprechen, also z.B.
>    #98.123 p"Feld 123" ..
>    Dann kommt nur das erste von mehreren .-Feldern raus, samt Zahl,
>    und bei
>    #98. ++ ...
>    kommen alle raus, jedoch gleichfalls MIT der Zahl am Anfang.
>    Mit diesem Misfeature könnte man u.U. leben, die Realisierbarkeit
>    wird aber noch geprüft.

"direkt ansprechen" wird nur dann wichtig, wenn man den einzelnen
Nummern eine Semantik spendiert, s.o.

Vorhandene Konstrukte

#98. ++ ...

sollten eigentlich durch die Ergaenzung

#98. ++ f"0123456789 " ...

~halbwegs sauber~ gerettet werden koennen. "Richtig sauber" wird
es dann, wenn f"0123456789 " nur dann ausgefuehrt wird, wenn der
Folgebuchstabe ein "." ist, Indikatoraktionen koennen hier testen,
wuerden aber die "++"-Iteration vorzeitig beenden. [Es fehlt eigentlich
seit jeher eine Schleifenkonstruktion, die trotz fallweiser Abbrueche
stets und unbedingt alle Wiederholungen durchlaeuft...]


> -  Bei Eingabe von  #nnn.~ xyz  hätte man gerne folgendes noch nicht
>    realisiertes Verhalten:
>    Es wird die letzte #nnn.zzz gesucht und auf die Zahl dann 1
>    aufaddiert, um die nachfolgende HFM-Kennung zu bilden.

Das scheint mir halbwegs wichtig, bzw. allgemeiner: (Auch) fuers Schreibfeld
sollte eine Methode existieren, die einem das Anfuegen einer Wiederholung
ohne Kopfrechnen erlaubt. Das geht natuerlich bereits ueber das hinaus,
was bislang mit Folgebuchstaben machbar ist, da benoetigt man ja
auch eine ASCII-Tabelle im Kopf um zu wissen, dass man nach 0-9
mit A-Z und dann a-z weiter macht.

[Vermutlich noch nicht behandelt sind die "+"/"-"-Buttons in Formularen?
Die brauchen vermutlich manchmal syntaktische Nachhilfe um zu wissen,
ob sie mit A-Z oder .1 - .ultimo zaehlen sollen]

Ich habe zwar noch nicht getestet, aber die skizzierte Loesung scheint
meinen "Maximalforderungen" von letzter Woche durchaus zu entsprechen.

Insbesondere ergibt sich jetzt ein ganz kanonischer Weg fuer die
Unicodisierung einer Datenbank:

* hat $M in der .CFG eine Liste fester Buchstaben, ist nichts zu
  tun (ausser dort wird ein Folgebuchstabe mit Wert > 126 angegeben)

* ansonsten kann "#kkf" schematisch auf #kk.F umgesetzt werden, dabei
  "F" der Zahlwert des Zeichens f.
  (je nach Schema kann man gewisse Folgezeichen ausnehmen, etwa 0-9,
  bzw. gewisse Felder wie #40, damit bestehende Sonderbehandlungen fuer
  #402 auch weiter funktionieren. Die Umsetzung scheint aber mittels
  Exportparameterdateien moeglich, insofern kann eine schematische
  Umsetzung ausgeliefert werden, die sich bei Bedarf noch individuell
  anpassen laesst)

(falls man allerdings vor lauter Begeisterung innerhalb derselben Kategorie
desselben Datensatzes einen Mix aus klassischen Folgebuchstaben und neuen
HFM-Wiederholungen nutzt, geht eine schematische Umsetzung nicht mehr
bzw. nur anders - da sollte man sich bei Eingaben also zurueckhalten, auch
wenn es naheliegt, nach "Z" oder "z" ganz "spontan" mit ".1" oder ".100"
weiter zu machen)

viele Gruesse
Thomas Berger