Re: Inputs and outputs

Norm,

Norm Walsh wrote:
> / Jeni Tennison <jeni@jenitennison.com> was heard to say:
> | 2. The <p:declare-output> and <p:output> pairings are a bit confusing.
> | At the pipeline level, we have the output declaration pointing to the
> | output of a step:
> [...]
> | At the choice level, we have the output of steps pointing to the
> | output declaration:
> [...]
> 
> If you look at some of the earlier examples in my first message,
> you'll see that I offered that as an explicit possibility. The
> important thing is that you know where the pipes go. It doesn't really
> matter if the port says what pipe goes in it or the pipe says what
> port it goes in (or both even).

My comment was only about the 'ref' design (which is the one I like most 
at the moment), and I was trying to make the point that if we adopt 
*that* design then we *have* to make explicit which way the connection 
is made with the outputs in <p:choose>, and that for consistency we 
should also do so with <p:pipeline> and <p:for-each>.

BTW, I think that the 'ref' design only works if you have compound 
names, because it means that inputs and outputs are given an implicit 
label so you only have to worry about forging the connection from one 
end (rather than giving both ends the same label). Otherwise you run 
into problems with <p:declare-output> within <p:choose> or <p:for-each> 
because these elements have to act as both anchors and pointers, and you 
can't do both with a single attribute.

> | 4. For what it's worth, I think non-technical users will balk at
> | having to include all the extra "pipework", such as declaring all the
> | inputs for the choice (so that it can standalone) and having a
> | bitbucket for unused inputs so that it passes static processing. I
> | don't think it scales very well when you have lots of branches that
> | use different inputs, or nested choices.
> 
> Yeah, I don't expect to get my way on that one, but I still think it's
> nice. I think of it something like a function declaration. You
> wouldn't refer to global variables from inside your function, would
> you? :-)

Well, sometimes, but I can tell you that I have absolutely no problems 
referring to function arguments from within an if/then/else (and that 
seems to be the more appropriate analogy)!

 > But with a little analysis, I can probably manufacture the
 > declarations myself. (From the point of view of my particular
 > implementation, I expect to get considerable benefit from the
 > self-contained nature of choose.)

My rule of thumb is that if an implementation can work something out for 
itself, then the user shouldn't _have_ to make it explicit.

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Friday, 21 July 2006 13:17:35 UTC