[Allegro] "acon -j srch.job" als Ersatz fuer SRCH.EXE

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg,

> Mir selber stoßen bei erster Durchsicht nur 2 Dinge auf:
> 
> 1. Der Umfang ist gegenüber dem Ausgangsmodell vervierfacht.
>    Das ist den vielen Kommentaren und funktional wertfreien
>    Ornamentierungen geschuldet, aber auch dem etwas üppigen Gebrauch

ich hatte auch untersucht, ob einige der gaengigen "automatischen"
Dokumentationssysteme (Doxygen, ROBODOC, und 50 weitere) eingesetzt werden
koennen, d.h. von den benutzten oder "unterstuetzten" Programmiersprache
so weit unabhaengig sind, dass man sie sogar noch bei FLEX/JOB
nutzen kann. Das Ergebnis ist etwas durchwachsen, demnaechst dazu
mehr. Derzeit sind in srch.job Kommentare enthalten, die von "Natural Docs"
< http://www.naturaldocs.org/ > (bei geeigneter Konfiguration)
verarbeitet werden koennen. Doxygen gefiel mir am besten (insbesondere
wegen der konfigurierbaren Zeichensaetze), da werden die Sprachen aber
durch eine einzige flex-Konfiguration (flex ist "Free LEX" und hat
nichts mit Adobe Flex oder a99-FLEX zu tun ;-) spezifiziert, das
wird fuer FLEX/JOB nicht gehen, weil diese Sprachen ja eigentlich nicht
formalisierbar sind...

Aufgeblaeht ist der neue srch.job uebrigens nicht nur wegen der Kommentare,
sondern weil haeufiger Fehlercodes abgefangen werden und auch ein bischen
Statistik getrieben wird: derzeit gibt es zwar erst fuenf Variable, die
alles moegliche mitzaehlen, aber einen Zaehler um eins zu erhoehen geht
ja mit nicht weniger als 5 Zeilen Code.


>    länglicher (mir manchmal deutlich zu langer) Variablennamen
>    ($OPTS.ExportParam[1], ojeoje, $ExpPar1 reicht doch dicke).

Oh, es haette $OPTS.ExportParameter[1] sein sollen: Ich hatte ja keine
neuen Namen einfuehren wollen, sondern stets die in a99.ini genutzten
Namen genommen. Natuerlich hatte ich zuerst auch ExPar und ExFile,
wegen hoeherer Logik habe ich es dann zu ExportParameter und OutputFile
aendern muessen. (korrigiert)



>    Gänzlich ohne Kommentar ist fast nur der Kernpunkt des Ganzen:
>    :srxdo
>    var kr
>    srX
>    Da findet die eigentliche Suche statt, und erraten kann das
>    aus dieser (unserer) Syntax wirklich keiner.

stimmt, die Teile, bei denen ich staerker auf den Original-srch.job
zurueckgreifen konnte, muessen noch besser kommentiert werden.




> 2. Warum muß es zusätzlich zu dem "array" $ARGV auch noch das,
>    im Inhalt gleichbedeutende, $OPTS geben, mit je unterschiedlicher
>    Namensgebung der eigentlichen Optionen?

der bisherige Ansatz, in der Kommandozeile nach " -d" zu suchen,
das folgende Argument herauszupfluecken und in einer Variablen
abzuwerfen ist nur eine 95%-Loesung: Es koennen ja in Anfuehrungs-
zeichen gesetzte Mehrwort-Begriffe ein einziges Argument sein,
insofern weiss man auch gar nicht, ob das gefundene " -d" ueberhaupt
ein Schalter war. Bei den Wiederholbarkeiten ist es aehnlich: -d
konnte srch.job noch explizit behandeln, weil ja klar ist, dass
nicht mehr als zwei Exporte gleichzeitig unterstuetzt werden, aber
- -U ist wirklich beliebig wiederholbar.

Insofern sind wirklich zwei Bearbeitungsrunden noetig: Erst einmal
die Analyse der kompletten Aufrufzeile und das Ablegen der gefundenen
Schalter nebst ihrer Argumente in einer geeigneten Struktur ($ARGV). Und
dann das herauspfluecken bzw. (-d, -U, ...) weitere Zerlegen in
fuer die weitere Verarbeitung geeignetere Strukturen ($OPTS)



>    Die Namensform $ARGV{-x} ist überdies doch etwas maniriert, wirkt
>    aber irreführenderweise syntaktisch bedeutungsvoll.

o.k., in JavaScript wuerde man konzeptionell nicht zwischen Hashes
und Arrays unterscheiden und stets $ARGV[-x] schreiben...

Wenn ich mich an die Einfuehrung der freien Variable erinnere, so
sind sie zwar mittels *eines* (genauer: zweier?) Hashes realisiert,
bedeuten aber dadurch nicht, dass jetzt die Flex/JOB-Sprache
Hashes oder Arrays haette. Als Trostpflagster ist aber dafuer die
Syntax so freizuegig, dass man - wenn man eigentlich gerne einen
Hash oder ein Array haette - die Benennung der freien Skalare so waehlen
kann, dass klar wird, dass man gerade an ein Hash oder Array denkt.


>    Solche Dinge schießen, finde ich, übers Ziel deutlich hinaus.
>    Die Kunst beim Programmieren zeigt sich in Kürze gepaart mit
>    Prägnanz, nicht in überbordender Eloquenz.

Wenn Sie in srch.job eine ueberfluessige (Anweisungs-)zeile entdecken,
bitte "Bescheid", schliesslich bin ich derjenige, der sich am
penetrantesten ueber die Langsamkeit von acon beschwert.

Andererseits ist die Anwendung beliebige Benutzereingaben auf
beliebigen Datenbanken, und da ist mein Standpunkt, dass auch
"unmoegliche" Fehlerbedingungen abzufangen sind (defensive
Programmierung), "Kuerze" also nicht bedeuten darf, dass man auf
auch nur einen einzigen Erfolgstest nach Anweisungen verzichtet.
Und ansonsten soll ja auch nicht jedes Skript sein eigenes
Universum eroeffnen, damit es auch fuer Dritte ansatzweise
les- und verstehbar bleibt. Variablen die hier leicht anders heissen
als dort, laden dazu ein, dass man auch im gleichen Skript uneinheitliche
Schreibweisen nutzt, die eigentlichen Flex-Kommandos moegen meinethalben
tolerant gegenueber Verschreibern sein, bei Variablennamen ist dem
aber nicht so und die Sprache bietet keine Hilfe, das zu entdecken.
Da hilft also nur bewusste Phantasielosigkeit beim codieren.

Die Programmbloecke :ARGV und :OPTS sind darueberhinaus bewusst
generisch gehalten, damit sie irgendwann als eigene Fragmente
ausgelagert werden koennen: Dann geraten die Verhaeltnisse auch
wieder ins Gleichgewicht (derzeit: 500 Zeilen zum Verarbeiten
der Kommandozeile gegen 200 Zeilen, die die eigentliche Arbeit
tun bzw. diese auswertend begleiten)


> Aber sonst kann ich mich damit sehr anfreunden und werde es nach
> einiger Straffung gerne in den Standard übernehmen.


Kommt drauf an, was Sie sich unter "Straffung" vorstellen: Immerhin
steht noch aus, #uiR loszuwerden, export Head/Foot zu unterstuetzen,
dann ist mir noch eine Optimierung eingefallen und es koennte auch
passieren, dass beim Testen Fehler auffallen oder naheliegende
Erweiterungen der Funktionalitaet gewuenscht werden: Wenn ich Ihre
Aenderungen (andere Anwender sind auch eingeladen, Verbesserungen
vorzunehmen und werden nicht anders behandelt) aus ideologischen oder
sonstigen Gruenden nicht akzeptieren mag, muessen Sie srch.job ploetzlich
wie zuvor selber pflegen und wenig waere gewonnen. Ich schlage daher
vor, dass Sie sich an zu langen Variablennamen und redundaten Kommentaren
einfach nicht stoeren oder sich zumindest nicht zu flaechendeckenden
"Verschoenerungen" des Codes hinreissen lassen.

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iJwEAQECAAYFAkwXOA4ACgkQYhMlmJ6W47MqnAQAv3oBO5K1CqwrwLeUxLjxZBpg
eQkLfKSu9VktkT6XKA4Rt2HNHSyZDwcoIu13Q1GqJ8ekln1KtR9yHUiyQxsxkWIA
hIEann1YdxTQ3pSpdzLxa0gzCACtCIYQWoQxg2C93rLWPtcDpVNe93cL5+gsTuKo
JwCZtIK/ZPcHUG3H1PE=
=T43E
-----END PGP SIGNATURE-----