You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I suggest adjusting the Workflow Client interface: introduce a distinction between the concepts of Stub and Proxy.
Currently, as a result of calling the method WorkflowClient::newWorkflowStub($class) (or WorkflowClient::newRunningWorkflowStub($class)), we do not receive a Workflow Stub (WorkflowStubInterface), but a proxy object that redirects calls of Workflow methods related to the Workflow interface. That is, the user interacts with the proxy object as with an implementation of the user's Workflow interface.
At the same time, we have methods WorkflowClient::newUntypedWorkflowStub(), WorkflowClient::newUntypedRunningWorkflowStub(), which return the very WorkflowStubInterface (type-level guarantee). That is, they work as expected.
Note
WorkflowStubInterface is convenient when, for example, you need to call the Describe method or the Update method with your own WaitPolicy.
We face two problems:
methods with the Stub postfix work differently: two out of four return WorkflowStubInterface, the other two return a proxy.
there is no proper way to get WorkflowStubInterface from a Workflow class. Both methods that accept a class return us a proxy.
In this commit, you can see changes in the WorkflowClientInterface interface. 1847f72
In the methods that currently return a Proxy, I've considered backward compatibility through the $proxy parameter. This will all be cleaned up in the next major version.
Calls to create stubs with $proxy=true will throw deprecation notices.
We can also discuss replacing the naming of Stub with Handle. Then we'll just make all the *Stub methods deprecated :)
The text was updated successfully, but these errors were encountered:
I have an idea
I suggest adjusting the Workflow Client interface: introduce a distinction between the concepts of Stub and Proxy.
Currently, as a result of calling the method
WorkflowClient::newWorkflowStub($class)
(orWorkflowClient::newRunningWorkflowStub($class)
), we do not receive a Workflow Stub (WorkflowStubInterface), but a proxy object that redirects calls of Workflow methods related to the Workflow interface. That is, the user interacts with the proxy object as with an implementation of the user's Workflow interface.At the same time, we have methods
WorkflowClient::newUntypedWorkflowStub()
,WorkflowClient::newUntypedRunningWorkflowStub()
, which return the very WorkflowStubInterface (type-level guarantee). That is, they work as expected.Note
WorkflowStubInterface
is convenient when, for example, you need to call the Describe method or the Update method with your own WaitPolicy.We face two problems:
Stub
postfix work differently: two out of four returnWorkflowStubInterface
, the other two return a proxy.WorkflowStubInterface
from a Workflow class. Both methods that accept a class return us a proxy.In this commit, you can see changes in the
WorkflowClientInterface
interface.1847f72
In the methods that currently return a Proxy, I've considered backward compatibility through the
$proxy
parameter. This will all be cleaned up in the next major version.Calls to create stubs with
$proxy=true
will throw deprecation notices.We can also discuss replacing the naming of Stub with Handle. Then we'll just make all the *Stub methods deprecated :)
The text was updated successfully, but these errors were encountered: