At 11:05 PM 11/25/2001 -0500, Michael G Schwern wrote:
>On Sun, Nov 25, 2001 at 07:54:11PM -0500, Charles Bailey wrote:
>> > Some alternatives:
>
>Here's a thought. A good chunk of the problems involve wedging the
>rich VMS env API into the narrow API of %ENV. To make matters worse,
>its trying to work as much like everybody's else's %ENV as much as
>possible.
>
>These two things seem mutually exclusive. So let's seperate them.
>
>You have %ENV which will strive for maximum compatibility and some
>other API that strives for maximum richness.
>
> print $ENV{FOO}; # prints the topmost FOO
>
> $ENV{FOO} = 'mybar' # sets FOO on the process table, original value
> # stored.
>
> delete $ENV{FOO}; # places FOO='' in the process table, original
> # value stored.
>
> exists $ENV{FOO}; # always false if delete() has been called on
> # this key.
>
>When the program exits, all original values are restored or removed
>from the process table as appropriate. I forget, does the process
>table disappear automatically anyway?
Not by default; the process may run another program that will see the same
logicals. It is possible to create logical names in "user mode" which means
they will go away when a program exits, but that has nothing to do with what
table they are in. I think you'd probably break a lot of existing code by
taking away the default persistence. Something like what you describe might
be the right thing to do for C<local %ENV> though, but the restoration would
occur at scope exit rather than program exit.
The magic in C<delete> and C<exists> could get interesting, for example
distinguishing between keys that are empty strings and keys that are undef
and keys that are nonexistent.
>The first step is writing up a module that can perform the full range
>of VMS environment manipulation *without* using %ENV. Once that's
>written, we can write a module on top of that which provides a tied
>%ENV and we can play around with various behaviors much more easily.
Clearly this would be nice to have.
>Of course radically changing the behavior for VMS %ENV will break
>backwards compatibility, but it seems it never was very well defined
>in the first place. There's always "use unixish qw(%ENV)".
There might be more code out there than you think that depends on the
existing behavior, and I don't think I've ever heard a complaint about the
existing behavior from someone coming from a VMS background. We've filled
in a few oversights and corrected a few inconsistencies, but Charles's
original scheme is pretty hard to beat for flexibility. You don't even have
to use logical names as your %ENV if you don't want to.
