From bc6b69ce718d40583d804f25e3c76febaac33a52 Mon Sep 17 00:00:00 2001
From: Ichthyostega
will sagen: es gibt keinen Zugriff, der vom Canvas ausgeht, durch die TrackBodies durchsteigt, und dann indirekt in den Cavas zurück greift. Denn -- zumindest im Moment -- handelt es sich um zwei klar geschiedene Belange: einmal das Rendern der Track-Struktur, und andererseits das platzieren von Clips auf dem Canvas
@@ -21543,9 +21541,7 @@
int hookAdjY (int yPos) override { return yPos + body_.getContentOffsetY(); };
@@ -22091,9 +22087,7 @@
Ursache ist ein schiefes Design
@@ -22905,9 +22899,7 @@
"was kann denn schon passieren??"
@@ -23692,9 +23684,7 @@
es ist hier kein by-Name-Zugriff,
@@ -25813,9 +25803,7 @@
Streng genommen würden wir in der Tat einen generischen Quer-Zugriffsmechanismus brauchen.
@@ -29411,9 +29399,7 @@
...jeodch nicht eigens im Test dokumentiert
@@ -33102,9 +33088,7 @@
im Beispiel: in dieser Closure wird zunächste eine Verdrahtung auf das button_down-Event angelegt. Wenn diese aktiviert wird, schaltet die die Beobachtung eines ebenfalls vorsorglich verdrahteten motion_notify_event ein, sowie analog das Warten auf ein button_up
@@ -39389,9 +39371,7 @@
der Gesten-Controller sollte hier nicht mitmischen
@@ -40307,9 +40287,7 @@
aber time::Control ist nur auf Zeiten ausgelegt
@@ -40685,9 +40663,7 @@
insofern muß es dann aber auch mit maximal großen Integer-Zahlen noch sauber funktionieren
@@ -40937,9 +40913,7 @@
einmal stark reinzoomen, und dann wieder zurück ⟹ Bereich ist beschnitten und kleiner geworden; das ist lästig, weil die nächst größere Stufe deutlich größer ist; meiner Einschätzung nach wäre es weniger lästig, wenn man ein kleines bischen zu viel sieht, zumal sich das auf der nächsten Zweierpotenz einpendeln dürfte
@@ -41205,9 +41179,7 @@
der Build-Prozeß belegt sukzessiv mehrere abstrakte Slots
...das wäre fatal, denn dann würde die Abstraktion zusammenbrechen; etweder der Builder, oder (noch schlimmer) das Library-Plug-in müßte Render-Engine-Internals instrumentieren
Damit wäre nämlich eine relativ sichere Storage auf dem Stack gegeben, und die Gegenwart der Parameter wäre trotzdem stets eindeutig dokumentiert. Auch im Hinblick darauf, daß vermutlich sehr häufig irgend welche Parameter fest gesetzt werden müssen (aber nicht per Automation bestimmt)
die explizite Behandlung würde damit in das konkrete Weaving-Pattern verlegt
in diesem Fall hätten alle Bindings die gleiche Port-Subklasse, würden aber beim Zugriff auf die Parameter einen virtual call machen
Ich wollte mehr, und deshalb halte ich die Stelle für das TurnoutSystem offen — obwohl auf gegenwärtigem Stand seine verbleibende Funktionalität komplett in die interne Mechanik integriert werden könnte. Auf diesem gegenwärtigen Stand kann ich die Vorstellung noch nicht weiter entwickeln, weil mir der klare Blick auf den realen Gebrauch in den tatsächlichen Proportionen fehlt — aber ich hoffe, daß sich dann aus dem Einsatz eines Baukasten-Systems irgendwann klarere Muster codifizieren lassen
Fazit: zurück zum ersten Konzept
einen Satz Parameter an anderer Stelle platzieren und anhängen
Der Zugriff erfolgt unchecked, aber ein typsicherer Zugriff soll durch einen compile-time-Overlay gewährleistet sein. Essentiell ist, daß die typsicheren Accessoren erzeugt werden können bevor die konkrete Storage-Adressen bekannt sind
+ der Umweg über lib::LinkedElements ist überflüssig, zumal ich durch direkte rekursive Implementierung auch noch eine klare Fehlermeldung erzeugen kann, falls ein Nachfolge-Extent noch nicht alloziert wurde +
+ + + +