iraf.net

Hi Dave,I saw Doug's reply to you. I agree that package parameters most closely
resemble the mechanism you mention. More complex sets of parameters
are best managed with a pset. With a package parameter the application
simply askes for parameter "foo". The CL searches for "foo" first in
the task parameters (including looking through other psets). It then
looks in the package that defined the task. What this means is that the
application can be the same and you can either include the parameter
in the task pset to be local to that task or leave it out and put
a parameter of the same name in the package which other tasks can
also use. The only thing is that it is either a task parameter or
a package parameter and not both.There is a little used construct that actually lets you have both. If you
have a task parameter, say "foo", which has a value of ")task.pname", this
acts as an indirect reference to some other parameter. There is also the
special case ")_.pname" where the "_" refers to the package. The advantage
of this is that you provide defaults that all point to, say, a package
parameter but each task can have the value overridden just for itself. I
don't necessarily recommend this because I'm not sure users generally
understand this but it has its uses; maybe in your application. Note
that even numeric parameter types can have this indirection string for the
value but once a user gives a value they cannot enter an indirection value
again except by unlearning to the default.Cheers,
Frank