QSpec objects versus passing quorum functions as arguments

[johningve]

QSpec objects versus passing quorum functions as arguments

[meling]

As I mentioned in the last meeting, I think we did have the function argument approach in an early version of Gorums. Maybe @leandernikolaus and @tormoder can help me confirm this; I looked at the code, but couldn't find any residue of this code.

I do think that our rational back then was that the qspec would then be decoupled from the caller's code; that is, the developer could think about making quorum calls and getting a single reply back and wouldn't have to see the actual quorum function as part of the execution path.

I think we also discussed back then whether or not to support both alternatives, and opted to pick just one approach for simplicity.

Any thoughts: @hanish520 @r0qs and others...

[meling]

I guess the question is whether or not a qspec belongs together with the configuration object. You could argue that the function argument approach can still be decoupled from the quorum call execution path by defining it outside the code path and just pass it as an argument; e.g., we could have a library of standard quorum functions that you pass in. But in this case, you cannot leverage the locally defined variables inside the quorum function.

[leandernikolaus]

I always thought of a quorum function and qspec as belonging to the configuration, rather than to a specific call.
Thus, I find it reasonable, if you want to use different qspecs, to rather use different configurations than passing different

I am unsure whether this is actually possible in the current gorums.

The disadvantage with qspecs, is that someone may actually modify state in these objects, which could be problematic and not thread safe.

[meling]

I'm closing this since there is no clear use case for the function closure approach. Should a use case arise, we can revisit the topic.