| Re: Name Space Conflicts [message #47859] |
Wed, 08 March 2006 13:17  |
![Paul Van Delst[1] is currently offline](theme/default/images/xoffline.png.pagespeed.ic.XRkd1fkXye.png "Paul Van Delst[1] is currently offline")
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
David Fanning wrote:
> Paul Van Delst writes:
>
>
>> Why not prefix it with FSC_ like some of your other code?
>
>
> Primarily because once you stick a prefix on a program,
> the code has a way of living (and embarrassing you!)
> forever. :-(
Well, if that's what you're worried about, the name of the file won't prevent it.
> And most of my program names are already too long to
> type comfortably, and I've had a typing class. I don't
> think there is a good solution. But I do think RSI ought
> to come up with something beside the order in !PATH
> for sorting this stuff out. In the IDLDE it is easy
> to rearrange your path to suit you, but this is pretty
> much a nightmare in the UNIX world, as far as I can
> tell. At least no one taking an IDL programming class
> from me and working with a UNIX machine has the foggiest
> idea how to do it.
If it's a toss up between a name too long to type comfortably and not working (now or in
the future) due to name space clashes, I'll take the former. And given my verbosity when
it comes to names (see below), "FSC_IMGSCL" is nothing! :o)
paulv
p.s. Good lord, did I write this? :
FUNCTION read_ascii_transmittance_coefficients, sensor_id, $
input_n_channels, $
predictor_index, $
transmittance_coefficients, $
file_path = file_path, $
sort_predictors = sort_predictors, $
smooth_coefficients = smooth_coefficients
And it's still relatively generic. I'd need to prefix it with "pvd_" or somesuch to be
super, ultra sure.....
--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC
|
|
|
|
|
|
| Re: Name Space Conflicts [message #47866 is a reply to message #47864] |
Wed, 08 March 2006 12:34  |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
David Fanning wrote:
> Folks,
>
> Nothing constructive here. Just whining and wishing for the
> good ol' days when only about 10-15 of us were using IDL.
> (And, of course, everyone at NASA Goddard.)
>
> There are so many LIBRARIES of IDL routines these days!
> Every time I write a new program I run into name space
> conflicts. The latest is IMGSCL, which even I thought was
> too obvious. But I did run a quick check against the NASA
> and JHUAPL libraries and when I didn't find a match
> I ran out and bought a Powerball ticket. But just now
> a Goggle search of "IDL IMGSCL" turns up 10-15 different
> programs. Sigh... (And I didn't have ANY of the six
> Powerball numbers, either.)
>
> I don't know what to do about this, generally.
Why not prefix it with FSC_ like some of your other code? Or prefix it with something
else, like the shortened category name under which you've organised this particular code
in your (backed up nightly) CVS repository (right?) :o)
paulv
Although
> in this particular case, I'm going to change the name
> to GMASCL to better reflect its use. We need an organization,
> similar to the ones who give you domain names, to sort
> all this out.
>
> Or, perhaps, someone can write one of those dot com
> name generator programs for us, so our programs can be
> "powerful and futuristic". :-(
>
> Cheers,
>
> David
>
>
--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC
|
|
|
|
| Re: Name Space Conflicts [message #47975 is a reply to message #47864] |
Thu, 09 March 2006 08:41 |
Tom Berger
Messages: 2
Registered: March 2006
|
Junior Member |
|
|
How about something analogous to cryptography where you have a
"namespace key" set in an environment variable or on the command line
that IDL checks before compiling a routine. This "public namespace key"
changes depending on which application you're working on. Then, inside
those routines that should be compiled with a given application there's
a uniquely defined "routine key" that fits with the namespace,
something like a C-code pragma instruction mechanism. If the compiler
doesn't find a matching key, it stops compilation and examines the next
instance of IMGSCL that it finds, continuing until a match is found at
which point it fully compiles the code. This would necessitate going
back into all of your routines and assigning these uniques keys, but
that could be automated pretty easily. This is just thinking out loud
- it could be completely stupid. But it seems like there needs to be
"another level" of namespace checking that goes on besides the brute
force !PATH method.
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
