Re: Parameters redux

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
[...]
| The advantages of this approach are that it draws on existing,
| familiar, mechanisms rather than introducing new ones, and thus is
| very powerful and flexible, but retains usability and transparency for
| simple cases.
|
| Thoughts?

I like it. I also considered putting parameters on an input so that we'd
be able to apply existing mechanisms; I just didn't come up with
anything as complete as your proposal.

I'd like to find a way to simplify it just a little more. Creating a new
kind of port, a parameter port, seems like an unfortunate bit of
complexity.

As far as I can tell, it's only necessary so that you know where to send
literal p:parameter elements that appear as children of the step. I
think I'd propose that instead of having a special kind of port, we
simply say that they go to a port named 'parameters'. It would be a
static error to put them on a step that didn't have an input port named
'parameters'.

The other things that you've done with parameter ports, the pre- and
post-processing examples, seem like they could be done with completely
ordinary input ports.

The only thing that we'd lose, with respect to your proposal as I
understand it, is that it wouldn't be possible to have a step with two
different parameter ports that had several literal p:parameter elements
that were sent to different parameter ports (or indeed any parameter
port other than the one named 'parameters').

I could live with that limitation and it feels like a significant
simplification to me.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | All knowledge is of itself of some
http://nwalsh.com/            | value. There is nothing so minute or
                              | inconsiderable, that I would not rather
                              | know it than not.--Dr. Johnson