Earlier quoted context omitted.
If you're worried about someone doing something other than calling a method in the lambda it's pretty straightforward to use an Expression > and validate the contents of the expression. Seems like that would make for a much better dev experience than this static Ref property pattern that you don't see anywhere else in C#.
It's not just that worry, it's the other reasons on top of that detailed in the post. But note that GP's post doesn't _call_ the method, it just references it which is basically what we are doing in the post. But for things like Durable Entities which _do_ call the method, yes we can prevent multi-use of the lambda arg but there are other problems (forcing interface/virtual, can't allow other args, sync vs async, etc…
Temporal .NET – Deterministic Workflow Authoring in .NET
21–30 of 51 posts
Re: Temporal .NET – Deterministic Workflow Authoring in .NET
#22Earlier quoted context omitted.
Activities may actually run on completely different systems than where the workflow calls execute on. All "execute activity" is from a workflow perspective is telling Temporal server to execute an activity with a certain string name and serializable arguments. Everything else is sugar. So if you're gonna use a type caller-side to refer to the name and argument types, you can't instantiate it fully (its constructor ma…
Lamba/Func/Expressions are doing exactly this in C#, there is no instantiation required. Creating a unusable Ref object is jumping through hoops. You can parse an expression to serialize it and run it on a different server etc See e.g. https://github.com/6bee/Remote.Linq
Of course the "Ref" pattern is user-choice/suggested-pattern, it's not a requirement in any of our calls that just take simple delegates however you can create those delegates. So I may be able to work it in there.
Re: Temporal .NET – Deterministic Workflow Authoring in .NET
#23Earlier quoted context omitted.
It's not just that worry, it's the other reasons on top of that detailed in the post. But note that GP's post doesn't _call_ the method, it just references it which is basically what we are doing in the post. But for things like Durable Entities which _do_ call the method, yes we can prevent multi-use of the lambda arg but there are other problems (forcing interface/virtual, can't allow other args, sync vs async, etc…
I'm not really arguing that your pattern _doesn't work_, I just think you've created an unnecessary new pattern to solve an already solved problem. Using expressions with lambdas is pretty standard in C# when you need to reference a method or property without calling it immediately. Entity Framework is an obvious example, mocking libraries like Moq, and at least one that I know of (Hangfire) uses expressions to seria…
Re: Temporal .NET – Deterministic Workflow Authoring in .NET
#24Earlier quoted context omitted.
Lamba/Func/Expressions are doing exactly this in C#, there is no instantiation required. Creating a unusable Ref object is jumping through hoops. You can parse an expression to serialize it and run it on a different server etc See e.g. https://github.com/6bee/Remote.Linq
Hrmm, I will investigate using an expression tree for this (now's the time while it is alpha). I was hoping to avoid people having to create lambdas. I hope I don't run into overload ambiguity with the existing `ExecuteActivity` calls where you can just pass an existing method as Func param. I will investigate this approach, thanks! Of course the "Ref" pattern is user-choice/suggested-pattern, it's not a requirement…
Re: Temporal .NET – Deterministic Workflow Authoring in .NET
#25Re: Temporal .NET – Deterministic Workflow Authoring in .NET
#26For those not familiar with workflows as code, a workflow is a method that is executed in a way that can't fail—each step the program takes is persisted, so that if execution is interrupted (the process crashes or machine loses power), execution will be continued on a new machine, from the same step, with all local/instance variables, threads, and the call stack intact. It also transparently retries network requests…
Re: Temporal .NET – Deterministic Workflow Authoring in .NET
#27Re: Temporal .NET – Deterministic Workflow Authoring in .NET
#28For those not familiar with workflows as code, a workflow is a method that is executed in a way that can't fail—each step the program takes is persisted, so that if execution is interrupted (the process crashes or machine loses power), execution will be continued on a new machine, from the same step, with all local/instance variables, threads, and the call stack intact. It also transparently retries network requests…
Re: Temporal .NET – Deterministic Workflow Authoring in .NET
#29Re: Temporal .NET – Deterministic Workflow Authoring in .NET
#30Earlier quoted context omitted.
Lamba/Func/Expressions are doing exactly this in C#, there is no instantiation required. Creating a unusable Ref object is jumping through hoops. You can parse an expression to serialize it and run it on a different server etc See e.g. https://github.com/6bee/Remote.Linq
Hrmm, I will investigate using an expression tree for this (now's the time while it is alpha). I was hoping to avoid people having to create lambdas. I hope I don't run into overload ambiguity with the existing `ExecuteActivity` calls where you can just pass an existing method as Func param. I will investigate this approach, thanks! Of course the "Ref" pattern is user-choice/suggested-pattern, it's not a requirement…
E.g. https://docs.hangfire.io/en/latest/background-methods/passin...
BackgroundJob.Enqueue(x => x.Send(13, "Hello!"));