What was the design decision behind requiring false for success and true for failure in rename scripts? This is in reference to the GetNewNameData event.
A return statement is not required in many scripting languages and the implicit value if nothing is explicitly returned is 0/false.
This standard goes back a long way. You shouldn't think of the return value as TRUE or FALSE, but as a Result or Return code. The 0 value was used as GOOD or OK, so that all the non-0 codes could be used to represent FAILURE codes. Why waste billions of return values (non-zero), just to conform to the 1=TRUE, 0=FALSE Boolean paradigm?
Technical reasons aside, what I do to not get brain wrecked while working with frameworks or environments in which the return values do not match your inner feelings, is declaring a variable or constant with the technical correct value but easy to understand name and return that instead of the plain value. You can have mutliple of these as well to make reading the code even more easy. FAILURE_USERABORT, FAILURE_BADPARAMS and so on, all mapping to the same "true" or "false" or whatever.
Is that why we need to return "true" for script commands which failed? o) Sounds wrong everytime I read it, but it matches what you said. o)
Ok, I think I may have had a misunderstanding of how the rename dialog works. GetNewNameData.newname is immutable, right?
So, for each item to rename...
I must return a string if I want to change the current item's name from within the script. If the script returns false, the current item may still be renamed based on other settings and actions in the rename dialog. However, if the script returns true then DOpus skips the current item without renaming and moves to the next item.
Does that sound right?
Ok, so could you fix the rename functionality so that returning true will cause the rename to happen and returning false will prevent it? That way it will work as programmers expect as the current implementation is backwards.
No, that would break many existing rename scripts, and it is the way it is now on purpose.
It's only backwards if you think of it as success/failure, instead of the correct skip/no skip.
As a programmer with 30 years experience I have zero issue with it. And, changing it will break all existing rename scripts.
But what is the purpose? That was my original question in my first post.
Good for you, but my brain works differently and I find that it violates the principle of least astonishment for me. I'm adding a comment to every script I'm writing to alert me because I'm sure it's going to confuse me if I open one of these scripts six months from now.
Do not write comments, use the var trick! o)
Good for you, but my brain works differently and I find that it violates the principle of least astonishment for me. I'm adding a comment to every script I'm writing to alert me because I'm sure it's going to confuse me if I open one of these scripts six months from now.[/quote]
Over 30 years I've learned that the only reliable principle of least astonishment is to read the docs (and I certainly don't trust my memory anymore 
)
IMO solution for this is simple - some variable in script that set Opus to return "true" instead of "false", for those who wants write their own script and are get "true" for success, not for failure. Second is adding one small options in "Advanced" configuration that swtich it for those who wants it. Third... well, it's user solution - writing own procedure that calls original function but returns opposite values.
So if the script function simply returns (without explicitly returning true or false or a string) then the changes made by the rest of the dialog/preset are still applied.
But then changing that could break any existing scripts, e.g. taken from the forum or ones which come with the program.
Thanks, Leo. So it sounds like my thinking in this post (Why is false used for success and true used for failure in rename scripts? - #5 by Matt2) was correct?
What is the var trick?
This.. o)