Differences

This shows you the differences between two versions of the page.

--- en:toolworks:docs:apparatus:deferred [2022/06/01 20:05] – vladius
+++ en:toolworks:docs:apparatus:deferred [2022/06/08 22:06] (current) – Добавил ссылку на внутреннюю документацию jispar
@@ Line 1: / Line 1: @@
 ====== Deferred Operations (Deferreds) ======
-It's no secret and if fact by design, that you can't execute methods that change a Subject's structure when using the Solid semantics. That essentially means you can only change the state of the individual Traits themselves, but not add nor remove the Traits themselves. The main advantage of the Solid enchaining is that it provides for the concurrent Operating and it would certainly be great to have more flexibility while evaluating the multi-threaded processing.
+It's no secret and if fact by design, that you can't execute methods that change a Subject's structure when using the Solid semantics. That essentially means you can only change the state of the individual Traits themselves, but not add nor remove the Traits themselves. The main advantage of the Solid enchaining is that it provides for the concurrent [[en:toolworks:docs:apparatus:operating|Operating]] and it would certainly be great to have more flexibility while evaluating the multi-threaded processing.
 So there come handy the deferred operations (or //Deferreds// for short). Like the naming implies, those are not executed immediately but are instead delayed for a later, more suitable occasion. Please note, that the Deferreds API is available for C++ only, since the whole Solid semantics is also C++-based and it's not possible to Enchain into a Solid Chain in Blueprints.
@@ Line 58: / Line 58: @@
 </code>
+====== Applying =====
+Until when? This is quite a logical question when dealing with something that is deferred by design. And the default answer is "when the time is right". That essentially means that the behavior is automatic by default, i.e. when the corresponding Mechanism's Chain gets disposed and the current active state is non-Solid.
+The default automatic behavior minimizes the effort and guarantees that the Deferreds get applied accordingly, but maybe you would like to have more control on when and where the application is happening. This is exactly why the concept of //Deferreds Applicators// was introduced.
+Deferreds Applicators are created explicitly, by calling the [[appi>class_a_mechanism.html#ac658045eedfb7def7bd238dae45cc676|UMechanism::CreateDeferredsApplicator]] method as in:<code cpp>
+{ // Start of the explicit scope.
+	auto Applicator = Mechanism->CreateDeferredsApplicator();
+	Mechanism->EnchainSolid(...)->OperateConcurrently([](){
+		// Your first mechanic producing deferred operations.
+	});
+	// The Deferreds won't be applied at this point.
+	Mechanism->EnchainSolid(...)->OperateConcurrently([](){
+		// Your second mechanic producing deferred operations.
+	});
+	// Now the Deferreds get actually applied.
+} // End of the explicit scope.
+</code>
+Note that the Applicator is actually introduced within its own explicit scope (the curly brace'd region). That is in fact done on purpose since the Applicator will apply the pending changes right when it is destroyed, which is guaranteed by ''Applicator'' being a local (automatic) variable and the ''{}'' scope.