Ich habe da mal eine Frage zu Spring.Event<T>.

An sich ist beim Event sehr wenig öffentlich: Add(T) , Remove(T) , Clear() und die Eigenschaft Enabled . In früheren Spring-Versionen gab es z.B. noch Count .

Ich bin verwirrt weshalb beispielsweise von TEvent<T> das Array Handlers: TArray<TMethodPointer> nicht öffentlich lesbar ist.

Ein konkreter Anwendungsfall: Ich möchte bei einem Event bestimmte Handler temporär entfernen und später wieder hinzufügen. Mit der derzeitigen Implementation geht das nicht.

Mir geht es nicht darum wie man das ändern könnte, sondern ich möchte die Motivation hinter dem Design verstehen. Der Urheber liest ja hier im Forum mit


PS: Was spräche denn nun bspw. gegen so etwas hier:

markieren

Code:

diff -r 8b40c231f18a -r 72569be88490 Source/Base/Spring.pas
--- a/Source/Base/Spring.pas   Fri Jan 26 11:23:01 2018 +0100
+++ b/Source/Base/Spring.pas   Fri Jan 26 20:24:57 2018 +0100
@@ -923,6 +923,7 @@
   IEvent<T> = interface(IEvent)
   {$REGION 'Property Accessors'}
     function GetInvoke: T;
+    function GetHandlers: TArray<TMethodPointer>;
   {$ENDREGION}
 
     /// <summary>
@@ -939,6 +940,7 @@
     ///   Invokes all event handlers.
     /// </summary>
     property Invoke: T read GetInvoke;
+    property Handlers: TArray<TMethodPointer> read GetHandlers;
   end;
 
   Event<T> = record
@@ -958,10 +960,12 @@
     procedure Remove(const handler: T);
     procedure RemoveAll(instance: Pointer);
     procedure Clear;
+    function GetHandlers(): TArray<TMethodPointer>; experimental;
 
     property CanInvoke: Boolean read GetCanInvoke;
     property Enabled: Boolean read GetEnabled write SetEnabled;
     property Invoke: T read GetInvoke;
+    property Handlers: TArray<TMethodPointer> read GetHandlers;
     property OnChanged: TNotifyEvent read GetOnChanged write SetOnChanged;
 
     /// <summary>
@@ -9625,6 +9629,12 @@
 {$ENDIF}
 end;
 
+function Event<T>.GetHandlers(): TArray<TMethodPointer>;
+begin
+    EnsureInitialized();
+    Result := TArray.Copy<TMethodPointer>(fInstance.Handlers);
+end;
+
 initialization
   Init;

Strikte API, klare Kapselung, kein Rumfuckeln an Interna und vor allem keine "braucht einer von 100" Features.
Daher auch das Entfernen von Count, es interessiert einfach nicht für den Anwendungsfall eines Multicastevents.

Ungeachtet deiner Motivation, das zu brauchen, neige ich zu der Meinung, dass es nicht Aufgabe des Events ist, bestimmte Handler an oder aus zu schalten, sondern einer anderen Komponente (Stichwort SRP).

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).

Die Reihenfolge zu wissen oder gar zu ändern (Prioritäten und so) war gar nicht der Plan. Ich wollte nur wissen was überhaupt drin steckt.

Bis auf das von außen aufrufbare Invoke() entspricht das Spring4D-Event<T> somit , um bei C# zu bleiben, wahrheitsgemäß dem event in C#. Was ich wohl suchte war eher das Delphi-Gegenstück zum Delegate .