On Fri, 6 Jun 2003, Peter W. Draper wrote:
> The problem, as I see it, is namespace pollution. We may have a smallish
> set of commands per package at present, but it's only going to grow, I
> remember when KAPPA had about 10 commands (got the SUN around somewhere),
> and there were a few packages, look at it all now. Any choice we make must
> be at least scalable in principle. Keeping things in separate directories
> per package is almost guaranteed to be manageable, just not as convenient.
>
> One thought I've toyed with is just to have the "entry points" in the lib
> and bin directories, so our main jar files lives in "lib" and resolve into
> sub-directories for extra and third party stuff, which is OK, but for
I'm inclined to support that.
> commands you'd then start writing things like:
>
> % kappa cadd in=xxx const=10 out=xxx
> % kappa cmult in=xxx ....
this is how I've done the ndtools (proto-)package - mainly driven by
the fact that writing the scripts is a bit of a pain (not necessarily
a good reason I admit). It would be possible to do it like this
and have a bunch of scripts one-per-task within the bin/package directory
so you could refer to them either way .. or maybe that's getting
a bit baroque.
I agree that there is a namespace problem for 'toolkit' type packages
following the KAPPA/CCDPACK/FIGARO/etc model. But packages which are
principally a GUI tool like Treeview & TOPCAT are not
going to proliferate the number of commands associated with them,
which is why I've put them straight in the main bin directory.
Mark
--
Mark Taylor Starlink Programmer Physics, Bristol University, UK
[log in to unmask] 0117 928 8776 http://www.star.bris.ac.uk/~mbt/
|