Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: p:finally cannot have a primary output port #829

Closed
ndw opened this issue Jul 6, 2019 · 4 comments

Comments

Projects
None yet
2 participants
@ndw
Copy link
Contributor

commented Jul 6, 2019

We have two constraints:

  1. All of the subpipelines of p:try must have a consistent primary output port.
  2. All of the output ports of p:finally must be distinct from any other subpipline's output ports.

It follows that if any (and therefore all) of the (non-final) branches of the p:try have a primary output port, the p:finally can't because 1 and 2 above. And if none of the non-final subpipelines have a primary output port, p:finally can't either because of 1.

I think we should say that explicitly somewhere.

(Alternatively, I think we could imagine a universe in which constraint 1 and 2 only apply jointly; if none of the non-final subpipelines have a primary output port, the p:finally is allowed to as long as it has distinct name. But I don't think we should imagine that universe.)

@ndw

This comment has been minimized.

Copy link
Contributor Author

commented Jul 6, 2019

If there's agreement on the point above, a subsidiary question arises. Consider:

<p:try>
  <p:output port="main"/>
  ...subpipeline...
  <p:catch>
    <p:output port="main"/>
    ...subpipeline...
  </p:catch>
  <p:finally>
    <p:output port="finally"/>
    ...subpipelinee...
  </p:finally>
</p:try>

According to the rules, the "finally" output port is primary because it doesn't say that it's not and it's the only output port from that subpipeline.

We could force users to put primary="false" on the port, or we could special case the rule that makes the output port primary.

@ndw

This comment has been minimized.

Copy link
Contributor Author

commented Jul 6, 2019

On further reflection, I think we should require primary="false". If we make it implicitly not-primary, then it won't connect to the last step by default and that's going to be confusing since it will look like it should.

@ndw

This comment has been minimized.

Copy link
Contributor Author

commented Jul 11, 2019

No one's commented, can I assume that means my proposal is non-controversial? The p:finally must not have a primary output port?

@xml-project

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

👍

@ndw ndw self-assigned this Jul 11, 2019

@ndw ndw closed this in 793c32b Jul 11, 2019

ndw added a commit that referenced this issue Jul 11, 2019

Merge pull request #835 from ndw/iss-829
Attempt to resolve #829
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.