comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: Namespaces (redux)
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: Namespaces (redux) [message #32223 is a reply to message #32222] Wed, 25 September 2002 08:32 Go to previous messageGo to previous message
JD Smith is currently offline  JD Smith
Messages: 850
Registered: December 1999
Senior Member
On Wed, 25 Sep 2002 00:55:59 -0700, Reimar Bauer wrote:

> JD Smith wrote:
> This is fine for some people who haven't access to html servers to put
> some projects there, but I like also to add only the URL too. At the
> moment I am waiting a bit how it goes on.
>
> Some time ago as dejanews has gone we have had a lot of trouble because
> there was no access to the archive. If now the experience of this group
> is splitted into rsinc forum and idl-pvwave we will lose again much of
> the results of discussions and ideas. I don't believe that's the rsinc
> forum is accesible by google forum search or am I wrong.
>
>
>> What can we do to
>> preserve this vanishing resource? A few guidelines come to mind:
>>
>> 1. Use Objects. Object methods don't count against the namespace,
>> since they're encapsulated beneath the class name. Use unique
>> class names. "Box" is probably not a good name for a class.
>> "tvRubberBandBox" might be better.
>
> Later on for some new routines this is possible. But what to do with the
> actual lib.
>
>
>> 2. If not using objects, imitate their namespace parsimony by
>> consistently prepending a class-like prefix to all related
>> routines...
>> e.g. tvRubberBandBoxDisplay.pro, or tvRBandBox_display.
>
> uppercases in routine names arent't accesible by unix or linux. Each of
> these routines must be compiled first. Who has asked for this feature
> before, if no one I will do it.
>
> This changing is more complicated as the changes rsinc did.
>
> In the past it was easy to add a new library for me because there
> weren't much available for athmospheric science. But at the moment it is
> difficult by source. By idl binary it isn't. This was one of the reasons
> why I have written my compile routine. The whole plot (plotxy,plot2d ..)
> environment of our library is stored in the plotprepare.sav file. And by
> using the initialising script plotprepare,plot this is loaded at once.
> After loading the sav file you have access to an info function
> x=plotprepare_info() where you can get informations about the sources.
> All sources are available in the catalog so you don't miss something. I
> added to the sav file a lifetime of about I believe one month, because
> if you are working on a library the functionality get more
> improvements.

This of course doesn't really solve the problem at all, but merely
circumvents it in a confining way. By creating a SAV file of your code,
you've just found a clever way to put your routines in front of other
routines on the !PATH. The routine shadowing still exists, but you've
guaranteed yours comes out on top.

What if I have *another* plotxy command from another library (or one I
created myself)? After I load your binary, that will no longer be
accessible. The idea is to "preserve", not "capture" the namespace.
Another route along these lines many packages have gone is to provide a
shell script which sets or modifies !PATH before running IDL with the
custom package. This provides a similar namespace "capture", but suffers
from an even worse form of the same problem: now I can't use *any* of my
other routines from other libraries when running the package!


>> 3. Resist the urge to give routines short catchy names, especially if
>> they will ever be distributed (even if just emailed to a
>> colleague). To save time for interactive use, consider using local
>> "abbreviation" routines which will never be distributed, and which
>> call longer-winded programs, e.g.
>>
>> pro tvrbd, args, _EXTRA=e
>> tvRubberBandBoxDisplay, args, _EXTRA=e
>> end
>>
>> Never call these interactive abbreviation routines directly in any
>> code.
>
> This don't solve the problem, then the filenames and routines are
> doubled.

It solves the problem of users who are motivated, by typing laziness, to
pick very short, and thus incredibly wasteful to the namespace, routine
names. I for one never use this, because IDLWAVE completes my routine
names for me, usually after just a few keystrokes (yes, even for object
methods).

>> 5. Look before you leap. An excellent (if increasingly outdated)
>> online-browser for almost all widely distributed libraries of IDL
>> code is available at:
>>
>> http://www.astro.washington.edu/deutsch/idl/htmlhelp/
>>
>> Use it to help you pick unique names, but don't imitate the
>> spendthrift ways of our forerunners: we've inherited the problem
>> from them, and must act to counter it.
>
> I thinks it is easier if we can share idlwave_catalog.el files with the
> library routines.

Reimar is referring to a system I've proposed for IDLWAVE whereby
widely-distributed libraries would have a catalog prescanned and included
with the distribution. Of course, IDL will still do nothing about it if
you have shadowed routines on your !PATH. IDLWAVE can at least alert you
to this problem, but can't solve it (you have to compile one manually,
rename it, etc.... gets to be a pain if it's in a constantly updated
library directory).

Glad to be back from nameserver exile.

JD
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: mpeg
Next Topic: Re: 24-bit color on printer device

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Oct 09 23:05:44 PDT 2025

Total time taken to generate the page: 0.56106 seconds