Spring4D: Events

[mensch72]

Spring4D ist ein universelles BasisFramework "mit Konzept", so ist es OK hier auch nur das zu implementieren, was "alle brauchen" und deterministisch Test fähig ist.

Bei Multicast-Lösungen streiten sich eh die Leute, ob und wie man sauber bestimmt wann/wo/ob eine Zusatzeventfunktion abgearbeitet wird.
Selbst beim hochgelobten C# kann man nicht bestimmen, ob das Zusatzevent am Anfang oder am Ende der bereits existierenden MultiCastListe eingefügt wird.

Ich habe mir (auf Basis der Arbeit von STOXX) dazu eine eigene TMethodListe mit einem zusätzlichem PrioParameter realisiert.
Getreu dem altbekanntem und beliebtem Standard(Delphi)Konzept "BeforeXXX('+1')","OnXXX('0')","AfterXXX('-1')".
Wenn ich nix angebe läuft alles auf Prio'0' und entspricht dem "Spring4D" bzw. C# Konzept.


Da bleiben nun wieder die konzeptionellen Fragen:
1. Was ist besser, schöner, einfacher,... drei Multicastevents(BeforeXXX/OnXXX/AfterXXX) oder ein universelles Multicastevent mit Prioritätsparameter (wo auch noch mehr möglich)?
(ich habe es mir selbst "einheitlich" realisiert, weil ich ähnliches Problem bei der Standardversion von "AddAyncTask" hatte, da gab es auch keine Option zu bestimmen wo&wie ein neuer Task in die Warteliste eingereiht wird)

2. "Wie" Können/Sollen sich Prioritäten soweit ändern, das dies bis zu den Extremen "noch gelistet aber wird gar nicht mehr aufgerufen" bzw. "wird nun exclusiv ohne alles andere mit geringerer Prio aufgerufen" sinnvoll funktioniert?
(ich habe auch dies "als weil es geht" implementiert, aber immer wenn ich es "schnell mal" einsetze, finde ich später eine bessere und konzeptionell sauberere Lösung... für schnelle Debug/Test-Fälle oder mal fix einen QuickAndDirty-Patch hilft das durchaus... es zerstört jedoch jegliche verlässliche Programmstruktur, weil die reale Programmfunktion ist dann nicht mehr deterministisch und wird so un-dokumentierbar!... 100%: in Spring4D hat sowas definitiv nix zu suchen, schon gar nicht offen ungeschützt herausgeführt).