Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Sonstige Fragen zu Delphi (https://www.delphipraxis.net/19-sonstige-fragen-zu-delphi/)
-   -   Spring4D: Events (https://www.delphipraxis.net/195024-spring4d-events.html)

Der schöne Günther 26. Jan 2018 19:50

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

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

Ich bin verwirrt weshalb beispielsweise von
Delphi-Quellcode:
TEvent<T>
das Array
Delphi-Quellcode:
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:
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;

Stevie 26. Jan 2018 20:01

AW: Spring4D: Events
 
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).

mensch72 27. Jan 2018 22:41

AW: Spring4D: Events
 
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).

Der schöne Günther 29. Jan 2018 08:11

AW: Spring4D: Events
 
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-
Delphi-Quellcode:
Event<T>
somit , um bei C# zu bleiben, wahrheitsgemäß dem
Delphi-Quellcode:
event
in C#. Was ich wohl suchte war eher das Delphi-Gegenstück zum
Delphi-Quellcode:
Delegate
.


Alle Zeitangaben in WEZ +1. Es ist jetzt 19:10 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz