Re: Determining whether a pipeline has a (defaulted) output

Alessandro Vernet wrote:
> On 10/25/07, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:
>> [...]
>> This achieves the stated goal, namely that the output defaulting rule
>> can be applied w/o arbitrary recursion and analysis through named
>> pipelines.
> 
> To reiterate on the argument I made during the call today, it looks to
> me that this leads to a situation where to be valid, some pipelines
> need to declare their outputs, while others do not. I think this will
> create some confusion, as a pipeline author can't just look at the
> outputs declared on the pipeline (maybe written by someone else) to
> know what the outputs of that pipeline is.

I agree with Alessandro. With this definition, I could define a pipeline 
library none of whose pipelines defined their inputs or outputs, and 
everything would work absolutely fine. I could even call pipelines from 
inside my other pipelines and never have a complaint. Until I happened 
to call one as the last step in a pipeline (perhaps because I just 
comment out the following code during debugging). Then suddenly I get an 
error not about the pipeline I'm currently working on, but about the one 
that it's calling not having defined its outputs. I think this will seem 
really arbitrary.

On the other hand, I understand Henry's (and Richard's) urge to 
make/keep simple pipelines simple.

So what about a rule that says "if a pipeline is called *at all* then it 
must have declared its inputs and outputs explicitly". This keeps the 
neat defaulting rules for the common/simple case of a single pipeline to 
do a quick job, but means that if you're planning to expose your 
pipelines for other people to call, then you have to take the extra step 
of declaring the inputs and outputs to the pipeline.

Cheers,

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

Received on Thursday, 25 October 2007 19:54:03 UTC