[Allegro] Exportdatei

[Thomas Berger]

Hallo Herr Fischer,

> Nein, Entschuldigung, das war der falsche Befehl.
> Erst bei
>     open x name
>         Die Datei name wird zum Schreiben geöffnet.
>  wird der mit
>     export f filename
> gesetzte Parameter überschrieben, das kommt in etlichen Flexen vor, z.B. im erwähnten ald-erg.flx und im FTR.FLX für die Volltextsuche.

die beiden Befehle sind doch synonym?


>>> Bei mir kommt es oft vor, dass ich eine Exportdatei dauerhaft benutzen
>>> möchte und mir zwischenzeitlich diverse Ergebnismengen
>>> zusammensuche, die ich dann exportiere.
>>> Das wird dadurch behindert, dass die Datei bei allen Flexen mit
>>> Schreibvorgängen auf die Standarddatei zurückgesetzt wird.
>>
>> Mir scheint, dass "open x" und "close x" falsche Assoziationen wecken:
>> Die Dateien werden nicht geoeffnet oder geschlossen, in Wirklichkeit
>> wird nur der aktuelle Name der Ausgabedatei gesetzt bzw. auf das
>> Default zurueckgesetzt (allerdings wird sie beim "open" /geloescht/).
> 
> Hier meinen Sie jetzt "open x" nicht wahr (das wäre sonst wenig nützlich)?

Ja, ich meinte "open" im Gegensatz zu "close" oder "delete". Konkret
natuerlich "open x".


>> Tatsaechliche Ausgabebefehle schreiben dann, wobei die aktuell eingestellte
>> Datei jeweils geoeffnet und wieder geschlossen wird.
>>
>> Also: "open x" und "close x" sind Augenwischerei, bzw. um es freundlicher
>> auszudruecken, sie bewegen sich auf einer anderen Abstraktionsschicht
>> als die konkreten Dateisystemobjekte, die damit verbunden werden.
> 
> Wäre es nicht möglich, dass "open x" den Pfad der aktuellen Exportdatei auf einen Stack schreibt und "close x" ihn dann wieder herauspoppt?
> Das würde verschachtelte Flexe (wenn so etwas denn überhaupt wünschenswert
> ist) in dieser Hinsicht erleichtern, zumal etliche Flexe ja gar keinen
> erkennbaren Export erzeugen, wohl aber die Exportdatei verbiegen.

"Normal" in Programmiersprachen ist eigentlich, dass ein "open" [x] implizit
ein close des vorigen bedeutet (wenn es denn zum gleichen Handle erfolgt).
D.h. es duerte unzaehlige Alt-Flexe geben, die hier den Stack zum Ueberlaufen
bringen koennten.

Aber "normal" waere natuerlich auch, dass "open" und "close" Dateien
oeffnen und schliessen, und das ist hier definitiv nicht der Fall.


>>> Alternativ könnte bei solchen Flexen die interne Sondervariable gesichert
>>> und wiederhergestellt werden, da will ich mir allerdings nicht gerne eine
>>> Sammlung  von Privatflexen anlegen.
>>> Konzeptionell käme es mir korrekt vor, wenn allgemeine Flexe so gebaut
>>> würden, dass sie keinen Einfluss auf interne Einstellungen haben.
>>
>> Sehr viele Standardflexe retten und restituieren akribisch die Werte
>> von Ausgabedatei und Ausgabeparametern. Das ist allerdings nie optimal,
>> da das Neu-Laden der Ausgabeparameter etwas im Unklaren laesst, was
>> mit Kopf- und Fussteile etc. passiert: Die werden beim ersten/letzten
>> Export mittels der Parameter erzeugt, und diese Information ist
>> unbekannt...
> 
> Da sollten Flexe eigentlich nichts mit zu tun haben bzw. es sollte klargestellt werden, wann solche Mechanismen denn greifen.
> Führt z.B. ein Neuladen der Exportparameterdatei zur Ausgabe der Kopfdatei beim nächsten Export?
> Mir ist nie klar gewesen, wann Allegro oder Avanti denn einen Export für so
> abgeschlossen halten, dass sie den Fußabschnitt ausgeben, das hat zu eher
> unschönen Konstruktionen beim Export von HTML-Dateien geführt, die einen
> Fußabschnitt brauchen.

Das hat unter PRESTO alles noch halbwegs Sinn gemacht, m.E.
laesst es sich innerhalb der Flex- oder Jobsprache nicht
vernuenftig definieren ("es" = Sinnvolles Verhalten der
vorgegebenen Sprachkonstrukte). Das liesse sich nur retten,
indem es "Ausgabeobjekte" gaebe, also Tupel aus Parameterdatei
und Exportdatei, die ihren Zustand behalten, auch wenn
"zwischendurch" andere Flexe andere Ausgaben veranstalten.
Aber um die zu verwalten benoetigt man entweder ganz andere
Sprachkonstrukte oder eine noch weitergehende Form Ihres oben
skizzierten Stacks.

viele Gruesse
Thomas Berger