Open DaveBenham opened 4 years ago
Carlos and I have discussed that in email, but not quite like this. I want call
to make heap variables local, and we've thought about restoring some options on exit. Something else to consider...
Having an option for localized heap variables might be nice. But I wouldn't want to lose the ability to have global heap variables. They are mighty handy for returning values from CALLed procedures across the ENDLOCAL "barrier".
Yeah, we haven't been able to agree on the syntax on how to handle that.
How about new extensions:
call @setlocal [/[-]d] [/[-]e] [localVar[=value]]...
/d enables delayed expansion after first stashing existing state.
/-d disables delayed expansion after first stashing existing state.
/e enables extensions after first stashing existing state.
/-e disables extensions after first stashing existing state.
Remaining arguments would define local variables, stashing existing values somewhere
to be restored later, and optionally allowing initial local assignment. If no value is
specified, then the existing value would be copied into the local space. The local variable
could be an environment variable, heap variable, or settable @extension
call @endlocal
Simply drop local variables restore previous values and restore state of delayed
expansion and extensions.
Even if the above were implemented, @push
and @pop
would still be useful.
Yeah, that could work. Although it's rather funny that EB came about to avoid setlocal
.
I don't see any difference between @setlocal
/@endlocal
and @push
/@pop
?
You are right, Only a slight difference.
Nested @setlocal
is a strict stack of value collections that are restored in reverse order by @endlocal
- the @endlocal
does not take any arguments.
Each @push
is its own independent stack for a single variable. The @pop
requires the name of the variable stack to pop. This would allow something like
call @push var1
call @push var2
call @pop var1
call @pop var2
The pops do not have to match the order of the pushes.
Also, perhaps @endlocal
could automatically be called upon exit /b from a called routine, whereas push could survive exit /b from a routine. This would be analagous to SETLOCAL vs PUSHD
Each
@push
is its own independent stack for a single variable. The@pop
requires the name of the variable stack to pop.
Ah yes. :blush: That's not really the right name, then; @store
/@restore
might work better, although I'm not sure having both store and local is necessary. Another approach is the shell way: var=temp_value... command
, but that might be tricky to implement.
It would be very useful to have
@push
/@pop
extensions to provide a stack of values.So the following
would be greatly simplified to
It would be great if it supported environment variables, $heap variables, and
@extensions