XYplorer Beta Club

jacky wrote:

admin wrote:Difficult.

You mean copytext without feedback, and/or getinfo ? Cause the later would still be a nice useful addition...

I meant copytext without feedback. Of course it would be easy, but I don't like script commands to influence properties of native commands, or to make "script running" a special context where things run differently from normal. This leads to a mess in the code.

getinfo is easy and will be added soon.

TheQwerty wrote:I'd say global vars should live for the instance of XY.

Off hand I can think of 3 ways that I wouldn't find too bad to work with..

In no particular order:
1) We have $var already, so let's say those are local variables, but let's add a new prefix character that signifies a variable is global. Thus we could have $var = local and say &var = global.

2) Adapt Set() to have an additional argument to make the supplied variable global, but we'd need a decent way to use this without having to do Set($var, $var, g);

3) Add Global(var1, .., varN); to make the supplied vars global. Set() and UnSet() would still work on the vars, so to kill a global var you'd have to UnSet() it.

3.

PeterH wrote:

jacky wrote: I was thinking maybe global vars should only be available to scripts within the current/same "source" (e.g. script file, ...), so when one script loads another script file, there would be two sets of global vars, one per "source". But at the same time, "fully global" variables could be useful as well...

I think global vars shared over several independent scripts are essential. But there could be a modifier on defining a global var, requesting to free it at the end of the "current" script?

And another thing: for debugging the need for a command to display all names (and maybe values) of all currently defined global variables...

shared over several independent scripts... not sure. Could lead to surprises when you use foreign scripts (from other authors) that don#t know about your globals...

command to display all names (and maybe values) ... yes, good idea.

admin wrote:

TheQwerty wrote:3) Add Global(var1, .., varN); to make the supplied vars global. Set() and UnSet() would still work on the vars, so to kill a global var you'd have to UnSet() it.

3.

Just to be clear: that command would work "as in PHP", i.e. makes this variable global for the current script ? We're not saying global $foobar makes that variable global for each & every scripts of the current batch from now on, right?

admin wrote:shared over several independent scripts... not sure. Could lead to surprises when you use foreign scripts (from other authors) that don#t know about your globals...

That's true, but would only be the case when your script calls such a script and then does something else, and both scripts use the same variable and have it global! Would be a lot, plus having global vars shared among different script files could be pretty useful already (even more so later on when things like functions will be added...)

jacky wrote:

admin wrote:

TheQwerty wrote:3) Add Global(var1, .., varN); to make the supplied vars global. Set() and UnSet() would still work on the vars, so to kill a global var you'd have to UnSet() it.

3.

Just to be clear: that command would work "as in PHP", i.e. makes this variable global for the current script ? We're not saying global $foobar makes that variable global for each & every scripts of the current batch from now on, right?

admin wrote:shared over several independent scripts... not sure. Could lead to surprises when you use foreign scripts (from other authors) that don#t know about your globals...

That's true, but would only be the case when your script calls such a script and then does something else, and both scripts use the same variable and have it global! Would be a lot, plus having global vars shared among different script files could be pretty useful already (even more so later on when things like functions will be added...)

1. Yep, as in PHP.

2. I'll think about it. Later. I'm currently doing something competely different... you'll see.

Note that it's quite easy to have global vars that even live longer than an XY session using getkey/setkey and something like globalvars.ini...

admin wrote:2. I'll think about it. Later. I'm currently doing something competely different... you'll see.

Cant wait!

admin wrote:Note that it's quite easy to have global vars that even live longer than an XY session using getkey/setkey and something like globalvars.ini...

Yeah, I use INI files for such things already, but I don't like the idea of global vars lasting the entire XY session, for that it should IMO also go to an INI. I think global vars should only last for as long as the (current) script batch execution goes on...

Otherwise, we'd then be talking about "session variables", not global variables...

jacky wrote:

admin wrote:Note that it's quite easy to have global vars that even live longer than an XY session using getkey/setkey and something like globalvars.ini...

Yeah, I use INI files for such things already, but I don't like the idea of global vars lasting the entire XY session, for that it should IMO also go to an INI. I think global vars should only last for as long as the (current) script batch execution goes on...

Otherwise, we'd then be talking about "session variables", not global variables...

Same here!

admin wrote:

jacky wrote: ... I think global vars should only last for as long as the (current) script batch execution goes on...

Otherwise, we'd then be talking about "session variables", not global variables...

Same here!

A question: what's the use of global variables?

First something else: how to use subroutines and functions? I assume to use them, you need parameters and return-values. So that SRs + functions "can" use values of variables in calling scripts, and calling scripts after return can use values "calculated" in deeper levels.
Eventually you can return values by parameters to calling scripts. (A bit dangerous...)

I think, if this is possible there is not very much use for global variables on the "currently executing" scipts? (Not "no use", but not so very much.) But globals should not be used for substitution of parameter-usage

On the other side I imagine a sequence like
- select a directory (for destination), call a script to remember it and to initialize some global vars
- multiple: search and select some files (maybe pictures) and call another script to remember (accumulate)
- when ready, after all, call a 3rd script to make final actions with all this data
Or setting a global $debug to 0 or 1, to test it in many scripts to decide if msg-commands for debugging should be made: for switching on / off debugging you must not change your scripts, but only the contents of a global variable.
(Better: use between 0 and 5, and test: If $debug > 3 then msg ... to have different debug levels, 5 to debug all, 0 for nothing.)

For this I would need global vars spanning several scripts. (In other words: "last for life of XY".) For such things I see more use than for globals just in "current executing" scripts.

And: for both you have the problem of unique names: even if you use a subroutine from someone else inside your scripts, possible globals must be unique. So using global vars always forces use of conventions between all people for unique names (you will never get) or adapting names of global vars to local conventions for all "imported" scripts.

Another thing: in any script, I'd expect, a variable will be used as global only after being defined so. In this case a variable-name must only be unique in those scripts defining it as global - others would use a local value.

Back on this, because global vars aren't there, and so right now I either have to use clipboard (which I don't like cause it means losing the clipboard, messes the status feedback ...) or use getkey/setkey and a tmp.ini which I don't like that so much either, because especially for scripts using loops and a few "variables" it means a lot of read/write operations...

So, just in case it's easier/faster to do, how about when using e.g. "::memory" as file for getkey/setkey then XY actually uses memory and don't do no file i/o. It's no global var, but it's a way to share some among scripts from one batch execution, all without messing clipboard, status feedback, or bothering the HDD.

...

jacky wrote:Back on this, because global vars aren't there, and so right now I either have to use clipboard (which I don't like cause it means losing the clipboard, messes the status feedback ...) or use getkey/setkey and a tmp.ini which I don't like that so much either, because especially for scripts using loops and a few "variables" it means a lot of read/write operations...

So, just in case it's easier/faster to do, how about when using e.g. "::memory" as file for getkey/setkey then XY actually uses memory and don't do no file i/o. It's no global var, but it's a way to share some among scripts from one batch execution, all without messing clipboard, status feedback, or bothering the HDD.

...

Sounds like named arrays: $key["name"] = "value"; $a = $key["name"];

Later...

admin wrote:Sounds like named arrays: $key["name"] = "value"; $a = $key["name"];

Later...

hmmm.. well, actually no, I didn't really had arrays in mind here (though that would be nice of course), but a way to share variables among scripts (during a batch execution) without having to use either clipboard or INI files. My whole point was to hopefully bypass the "later" in your answer, because as I said right now it's messing with the clipboard & losing status feedback, or hammering the HDD through INI files.

So the idea was to use a "special" INI file, which would actually be stored in memory. Hence none of the aforementioned troubles, and because it would still be done using actual commands getkey/setkey it was hoping it might have been easier/faster to implement... hence coming sooner (rather than... )

The fact that there were sections used to store data was actually only due to re-using existing commands, not a need for named arrays. But if you'd rather create new commands to get/set such variables with only a name & the associated value, that's more than enough for me!

jacky wrote:

admin wrote:Sounds like named arrays: $key["name"] = "value"; $a = $key["name"];

Later...

hmmm.. well, actually no, I didn't really had arrays in mind here (though that would be nice of course), but a way to share variables among scripts (during a batch execution) without having to use either clipboard or INI files. My whole point was to hopefully bypass the "later" in your answer, because as I said right now it's messing with the clipboard & losing status feedback, or hammering the HDD through INI files.

So the idea was to use a "special" INI file, which would actually be stored in memory. Hence none of the aforementioned troubles, and because it would still be done using actual commands getkey/setkey it was hoping it might have been easier/faster to implement... hence coming sooner (rather than... )

The fact that there were sections used to store data was actually only due to re-using existing commands, not a need for named arrays. But if you'd rather create new commands to get/set such variables with only a name & the associated value, that's more than enough for me!

The problem is that that the INI API cannot handle anything in memory AFAIK. So I think you have to wait for global variables.