Re: Re: shadow-proofing a package
- To: mathgroup at smc.vnet.net
- Subject: [mg42734] Re: [mg42718] Re: shadow-proofing a package
- From: Dr Bob <drbob at bigfoot.com>
- Date: Thu, 24 Jul 2003 04:10:39 -0400 (EDT)
- References: <bfiu78$j8a$1@smc.vnet.net> <200307230425.AAA29123@smc.vnet.net>
- Reply-to: drbob at bigfoot.com
- Sender: owner-wri-mathgroup at wolfram.com
Why would Selwyn or I write a package that depended on a symbol we were
likely to use for storing a 4-week computation? Do we really look like
idiots?
On the other hand, that begs the question: why worry about shadowing at
all, if we can, instead, choose good names that aren't likely to conflict?
Bobby
On Wed, 23 Jul 2003 00:25:11 -0400 (EDT), Jens-Peer Kuska
<kuska at informatik.uni-leipzig.de> wrote:
> Hi,
>
> say you have stored the result of a 4 week computation in one
> of the variables that are removed by the package.
>
> Just load the package and destroy your work without a warning -- sounds
> great !
>
> Regards
> Jens
>
> Selwyn Hollis wrote:
>>
>> The following occurred to me as a way to prevent the shadowing problem:
>>
>> Before BeginPackage["blah`blahblah`"] put
>>
>> Remove@@( StringJoin["Global`",#]&/@
>> Intersection[Names["Global`*"],
>> {"name1", "name2", ... for all symbols defined in the package}] )
>>
>> This seems to work well. But surely there must be some downside to it,
>> or else it would already be the recommended way of doing things. What
>> am I overlooking here?
>>
>> -----
>> Selwyn Hollis
>> http://www.math.armstrong.edu/faculty/hollis
>
>
--
majort at cox-internet.com
Bobby R. Treat
- References:
- Re: shadow-proofing a package
- From: Jens-Peer Kuska <kuska@informatik.uni-leipzig.de>
- Re: shadow-proofing a package