Resolution 1, by itself, would enable a whole class of programmer bugs
that are impossible today.
Resolution 1 + 2, if I understand the semantics correctly means that a
message operation with noInitiate="false" will:
Case 1 - Correlation Set is Uninitialized - The message activity is
available for use and if a message is received then the correlation set
will be initialized.
Case 2 - Correlation Set is Initialized - The message activity is
available for use but will only accept messages that match the
initialized correlation set.
I think that noInitiate="false" allows for ambiguity in specifying the
programmer's intentions. I'm having trouble imagining compelling
scenarios, outside of start activities, where someone would explicitly
want a message activity that will run regardless of the initialized
status of its correlation set. In the specific case of start activities
I'm actually going to propose a different solution targeted at just that
problem.
I also think that noInitiate puts the burden in the wrong place in
regards to guarding message activities. In a world with noInitiate every
time a programmer has a message activity that wants to make sure to use
an initialized correlation set, which I believe will be the 80% case,
they will be forced to explicitly specify noInitiate = "true". I think
the burden should be reversed. Programmers should only be required to
specify something if they don't expect the correlation set to be initiated.
Thanks,
Yaron
Yuzo Fujishima wrote:
