carlos-montiers / enhancedbatch

Enhances your windows command prompt https://www.enhancedbatch.com
Other
5 stars 1 forks source link

Proposed @push / @pop extensions #32

Open DaveBenham opened 4 years ago

DaveBenham commented 4 years ago

It would be very useful to have @push / @pop extensions to provide a stack of values.

So the following

set $prevDelayedExpansion=%@delayedexpansion%
set @delayedexpansion=1
rem some code that requires delayed expansion
set @delayedexpansion=%$prevDelayedExpansion%

would be greatly simplified to

call @push @delayedexpansion=1
rem some code that requires delayed expansion
call @pop @delayedexpansion

It would be great if it supported environment variables, $heap variables, and @extensions

adoxa commented 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...

DaveBenham commented 4 years ago

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".

adoxa commented 4 years ago

Yeah, we haven't been able to agree on the syntax on how to handle that.

DaveBenham commented 4 years ago

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.

adoxa commented 4 years ago

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?

DaveBenham commented 4 years ago

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

adoxa commented 4 years ago

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.