Kontrollflussarchitektur bei Ereignissen: Geschmackssache?!?

[Der schöne Günther]

Vielleicht liegt es an der Uhrzeit, aber ich musste mehr als einmal lesen um es zu verstehen. Eine kleine Skizze vom Ablauf*hätte (mir zumindest) geholfen

In einem Satz zusammengefasst: An einem OnClick-Event hängen mehrere Handler. Einer dieser Handler ändert z.B. eine Eigenschaft was wiederum ein OnChange-Event auslöst. Sollte man nun

• Die Handler des OnChange-Events abarbeiten um danach die restlichen Handler von OnClick abzuarbeiten
• Oder die Handler von OnChange erst nach dem vollständigen Abarbeiten aller Handler des "laufenden Events" (also OnClick) abarbeiten

Richtig verstanden?

Vielleicht habe ich einfach noch nicht genug von der Welt gesehen, aber den "defer"-Ansatz habe ich weder irgendwo einmal gesehen, noch finde ich das in irgendeiner Weise intuitiv. Bei einem "Mach sofort"-Ansatz*könnte ich Events*deaktivieren, etwas tun und danach wieder aktivieren. Mit dem "defer"-Ansatz verliere ich das doch, oder?

Ganz zu schweigen von dem Mehraufwand. Was z.B. wenn ich einen Handler entferne, der aber noch in irgendeiner "Mache später"-Queue steckt? Schwierig. Mir fehlt ein konkretes Beispiel wo der "defer"-Ansatz irgendeinen Vorteil hat. Was hierdurch einfacher wird.*

Außerdem sehe ich nicht was an einem Event so "besonders" ist dass man es aufstauen sollte. Warum wird ein Handler der ein internes Feld ändert sofort ausgeführt, ein anderer der z.B. auf eine Property geht (deren Setter ein Event auslöst) aber später? Bzw. der Setter würde ausgeführt, nur der Code hinter dem Event nicht? Jeder*Code der hinter dem bewussten Ausführen eines Events steht müsste fortan davon ausgehen müssen, dass die*Folgen noch nicht eingetreten sind.

Ziemlich verwirrend. Vielleicht aber auch nur für mich.

PS: Mich haben deine "Beginnt mit"-Dinger verwirrt, vor allem da du erst ganz unten erklärst was du damit meintest. Lass die*Auflistung doch wie sie ist, das versteht denke ich trotzdem jeder.