5 ms·

>You're going to have to do that lifting anyways to create an instance for `e` that isn't really a usable instance. But this should never happen, these is no r

>You're going to have to do that lifting anyways to create an instance for `e` that isn't really a usable instance. But this should never happen, these is no reason to create an unusable instance. The real instance should be resolved in the same way however the current workflow resolves it.

kodablah 3y ago
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 may have side effects for when it really runs). You can jump through a bunch of hoops like requiring interfaces which is what some frameworks do. But in our case, we just decided to make it easy to reference the method without invoking it or its instance.
- 0xcoffee 3y ago
  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 https://github.com/6bee/Remote.Linq
  - kodablah 3y ago
    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<T, TResult> param. I will investigate this approach, thanks! 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.
    - progmetaldev 3y ago
      If it's possible to use both approaches without cluttering your API, that may be the best solution. I know a lot of more junior devs that have a difficult time wrapping their head around expressions in C#. Excellent library!
      - kodablah 3y ago
        After looking at it, I am concerned it is not possible for a clean experience. We have to give guidance and samples and we have to choose a way of referencing methods in those. Having ambiguous approaches is a bit rough. We may have to just move to expressions.
        progmetaldev 3y ago
        I completely understand. Either way, I still think the library is great and appreciate the work done to create it.
    - jcparkyn 3y ago
      As another point of reference, Hangfire also uses expressions for a similar use-case and it seems to work quite well. E.g. https://docs.hangfire.io/en/latest/background-methods/passing-dependencies.html https://docs.hangfire.io/en/latest/background-methods/passin... BackgroundJob.Enqueue<EmailSender>(x => x.Send(13, "Hello!"));
      - evntdrvn 3y ago
        Yup!!!

kodablah 3y ago

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 may have side effects for when it really runs). You can jump through a bunch of hoops like requiring interfaces which is what some frameworks do. But in our case, we just decided to make it easy to reference the method without invoking it or its instance.

0xcoffee 3y ago
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 https://github.com/6bee/Remote.Linq
- kodablah 3y ago
  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<T, TResult> param. I will investigate this approach, thanks! 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.
  - progmetaldev 3y ago
    If it's possible to use both approaches without cluttering your API, that may be the best solution. I know a lot of more junior devs that have a difficult time wrapping their head around expressions in C#. Excellent library!
    - kodablah 3y ago
      After looking at it, I am concerned it is not possible for a clean experience. We have to give guidance and samples and we have to choose a way of referencing methods in those. Having ambiguous approaches is a bit rough. We may have to just move to expressions.
      - progmetaldev 3y ago
        I completely understand. Either way, I still think the library is great and appreciate the work done to create it.
  - jcparkyn 3y ago
    As another point of reference, Hangfire also uses expressions for a similar use-case and it seems to work quite well. E.g. https://docs.hangfire.io/en/latest/background-methods/passing-dependencies.html https://docs.hangfire.io/en/latest/background-methods/passin... BackgroundJob.Enqueue<EmailSender>(x => x.Send(13, "Hello!"));
    - evntdrvn 3y ago
      Yup!!!