dxfmakros/doc/vf-parameter-struct-analyse.md

VarioFoerderer-Cluster — Analyse Parameter-Buendelung (Struct-Potential)

Bestandsaufnahme der globalen Variablen und Funktionssignaturen in Lisp/vf_core.lsp, vf_konstanten.lsp, vf_standard.lsp, vf_etage.lsp und vf_linienzug.lsp — als Grundlage fuer die Frage, ob sich haeufig gemeinsam durchgereichte Parameter zu einem Struct (in AutoLISP: eine benannte Alist) buendeln lassen, um Funktionssignaturen mit 5+ Parametern zu verkuerzen. Stand: 2026-09-01, rein analytisch, keine Codeaenderung.

Ausgangsbefund: globale Variablen

Die globalen Variablen der drei Module sind kein Parameter-Problem:

• vf_konstanten.lsp enthaelt ausschliesslich feste *vfk-*-Konstanten (Winkel, Laengen, Toleranzen), die einmalig per ssg-cfg-or/Guard gesetzt und direkt gelesen werden, nicht als Parameter durchgereicht.
• vf_core.lsp/vf_standard.lsp/vf_etage.lsp haben Init-Flags/Caches (*lib-initialized*, *ks-cache*, bogen-auf/bogen-ab), die Typ-Registry *vf-typ-registry* und wenige AS/ES-Massen-Offsets (aus-dx usw.).
• vf_linienzug.lsp haelt zusaetzlich Journal-/Replay-State (*vfl-journal*, *vfl-replay-queue*), Wizard-Dialog-State (*vflw-pending*, *vflw-menu-*) und neun parallele *vfl-acc-*-Globals als "Ketten-Akkumulator" (siehe Abschnitt 4).

Das eigentliche Problem liegt woanders: dieselben 4-8 thematisch zusammengehoerigen Werte werden wortwoertlich durch dutzende Funktionssignaturen durchgereicht, weil es dafuer noch keinen gebuendelten Wert gibt.

Bereits vorhandene Struct-Vorbilder im Code

Diese Muster existieren schon und sind das natuerliche Vorbild fuer eine Erweiterung (AutoLISP-Konvention: Alist statt echtem Struct):

• KS-Frame (P xu yu zu) — Punkt + 3 Achsvektoren als ein Wert (vf_core.lsp, frame in vf_linienzug.lsp)
• prefill-Alists (string-keyed, (cdr (assoc "key" prefill))) zur Dialogvorbelegung in vfs-dialog-eingabe-basis/vfs-dialog-winkel-verteilung
• *vf-basis-eingabe-felder* + vf-basis-eingabe-entpacken — eine benannte, geordnete Feldliste, generisch per foreach/nth entpackt
• ergebnis-liste-Eintraege (winkel L_GF L_VF gueltig) aus vf-winkel-solve/berechne-alle-winkel
• kette-rec in vf_linienzug.lsp — Positions-Accessor-Funktionen (vfl-kette-rec-ename usw.) ueber eine flache Liste
• *vfl-glied-schema* — Schema-Tabelle (Label -> Felddefinitionen) als struct-aehnliche Serialisierung pro Ketten-Glied

Funktionen mit den meisten Parametern

Funktion	Datei	Anzahl Parameter
vf-block-erstellen	vf_core.lsp	18
vf-make-label	vf_core.lsp	13
vf-dialog-berechnen-einfuegen	vf_core.lsp	12
variofoerderer-einfuegen	vf_standard.lsp	10
etage-foerderanlage-einfuegen	vf_etage.lsp	10
vfs-standard-dialog-berechnen-einfuegen	vf_standard.lsp	10
vfe-etage-dialog-berechnen-einfuegen	vf_etage.lsp	10
vfl-block-erstellen	vf_linienzug.lsp	10
vfl-modus-abbruch-sichern	vf_linienzug.lsp	9
vf-winkel-solve	vf_core.lsp	8
vfs-mitte-teil, vfl-vf-einheit, vfl-vf-einheit-abschluss	standard/linienzug	je 7
vfs-vf-koerper, vfl-insert-es-element, vfl3-es-fueller	standard/linienzug	je 5-6
die vier insert-hz-*-Funktionen	vf_etage.lsp	je 4-6

Struct-Kandidaten

1. geometrie-basis (deltaL deltaH richtung startpunkt hz seite [dim geruest-einzelmodul geruest-typ motorseite]) — identisch in vf_core, vf_standard, vf_etage UND vf_linienzug. Erweitert direkt das bestehende *vf-basis-eingabe-felder*-Muster. Groesster Hebel, da er in fast jeder Top-Funktion mit vorkommt.
2. ergebnis-geometrie (best-winkel L_GF1 L_GF2 L_VF richtung) — entspricht der Form der ergebnis-liste-Eintraege aus vf-winkel-solve; steckt in vf-make-label, vf-block-erstellen, vfs-mitte-teil, vfs-vf-koerper, variofoerderer-einfuegen, etage-foerderanlage-einfuegen.
3. hoehen (hoehe-von hoehe-bis deltaH) — klein, wiederholt sich in vf-make-label/vf-block-erstellen; evtl. eher in Kandidat 2 integrieren als eigenstaendig fuehren.
4. geruest-optionen (geruest-einzelmodul geruest-typ motorseite) — reist durch Dialog-/Edit-/Erstellen-Funktionen; Alternative: direkt in geometrie-basis aufnehmen statt separat zu fuehren.
5. ketten-meta (vfl-nummer anzahl-gf anzahl-vf hoehe-von hoehe-bis delta-l-total as-seite es-seite) — nur vf_linienzug, betrifft vfl-block-erstellen (10) und vfl-modus-abbruch-sichern (9).
6. Rotation-Paar (hz-winkel vert-winkel) (optional mit vorgerechneten sin/cos) — die vier insert-hz-*-Funktionen in vf_etage.lsp teilen dieses Paar plus dupliziertes Grad->Bogenmass/sin/cos; ein gemeinsamer Wert wuerde auch die Code-Duplikation beseitigen, nicht nur die Parameterzahl.
7. *vfl-acc-*-Akkumulator — kein Parameter-, sondern ein State-Problem: neun parallele globale Listen (*vfl-acc-lvf*, *vfl-acc-lgf*, *vfl-acc-gfwinkel*, *vfl-acc-richtung*, *vfl-acc-winkel*, *vfl-acc-motorseite*, *vfl-acc-gfbogen*, *vfl-acc-variokurve*, *vfl-acc-separator*), die konsequent zusammen gesetzt/gelesen werden. Ein Record statt neun losen Globals waere robuster gegen Vertipper/vergessenes Zuruecksetzen.

Mit Kandidat 1+2 allein liesse sich vf-block-erstellen von 18 auf ~6-7 Parameter bringen, vf-make-label von 13 auf ~5-6, und die gesamte 10-Parameter-Familie auf ~4-5.

Einschaetzung

Es besteht spuerbares Potential, aber mit Vorsicht: vf-dialog-berechnen-einfuegen haengt an der Typ-Registry (*vf-typ-registry*, berechne-fn/einfuege-fn) und wird von Standard-, Etage- und indirekt Linienzug-Pfaden aufgerufen. Eine Signaturaenderung dort zieht Aenderungen an allen drei registrierten Funktionen sowie den Edit-/Rebuild-Pfaden (vfe-edit-ent, vfl-edit-ent, Journal-Replay) nach sich. Empfohlene Reihenfolge bei einer Umsetzung:

1. Risikoarme Blattfunktionen zuerst (Rotation-Paar in vf_etage, vf-make-label).
2. geometrie-basis/ergebnis-geometrie als groessere, aber isolierbare Cluster.
3. Die Registry-Signatur (vf-dialog-berechnen-einfuegen) und die Edit-/Replay-Pfade erst zuletzt anfassen.

Stand jetzt: reine Analyse, keine Umsetzung angestossen.