I think this needs a standardized regulation.
What about a Script Menu setting that lets you pick "legacy return values" vs "consistent return values"? Old scripts could be setup to use the former and newer ones would pick the later?
A script function name should be understandable. But this renaming was a bad attempt - sorry.
Definitely hate that, it should not be a user setting, and it would make a mess of the code and be horribly confusing.A somewhat better (IMHO) approach I've considered is adding an @ parameter for script compatibility, e.g.@version 1.2 or something like that. In many, if not all cases compatibility could be handled by a lua file that wraps the relevant functions, so backward compatibility wouldn't need to bloat or complicate the C code. However, this doesn't really solve the issue for existing scripts in a clean way. I guess we could have the default be 1.2 compatible, but produce a warning or something for scripts that don't have the @version tag.All in all, I think I'd be more in favor of just breaking compatibility between releases. That's a big part of why we created a development branch and a stable branch, and I do believe that having consistent interfaces is worth it in the long run. Then again, I don't have a whole bunch of popular scripts to maintain.
All in all, I think I'd be more in favor of just breaking compatibility between releases. That's a big part of why we created a development branch and a stable branch, and I do believe that having consistent interfaces is worth it in the long run. Then again, I don't have a whole bunch of popular scripts to maintain.
There are really not a lot of good options that will not create massive confusion and pain.
Other than leaving things the way they are that is.
Or defaulting things so that @version type stuff "just works" for existing scripts.
Much as I hate to say this, the desire to "purify" the coding conventions at the expense of breaking a rather large installed base is questionable. If we do nothing, things will just carry on as they are.
The distinction between 1.1.0, 1.2.0, 1.3.0 etc means a lot to those of us that live here. And nothing to everyone else.
Well then that's a massive failure on my part. On of the main reasons to have an unstable branch is to be able to break compatibility and have a relatively clean transition.
Unfortunately, we've been telling people "oh yeah the trunk is unstable but it's probably stable enough to use so use it" and shot ourselves in the foot.
I don't have a good solution, but I lean toward leaving things pretty much as they are in 1.3 and breaking compatibility early in 1.4. We could introduce and @version type thing for 1.4, and show a warning "this script is designed for an earlier version of chdk" if it isn't present or is for the wrong version.
I'm fine with renaming this (again) but since my last attempt was bad, I'm waiting for a consensus of more than 1 before changing it again.
First we should define some standards for (new) script commands. These standards should enforced starting with version 1.3. It means, that all commands newly developed in Version 1.3 be provided in accordance with these standards. Older commands should remain untouched. They are well documented and there are many examples.
Quote from: reyalp on 05 / September / 2014, 17:44:50I'm fine with renaming this (again) but since my last attempt was bad, I'm waiting for a consensus of more than 1 before changing it again.Agreed. But hardly one is interested in such marginal things. It will be difficult to get other opinions.msl
In case there's a chance that the A/D converter input will ever provide the same functionality as the USB input, perhaps the function name should not include "usb"?
Started by Mac General Help and Assistance on using CHDK stable releases
Started by CoffeeGrip General Help and Assistance on using CHDK stable releases
Started by DavidB « 1 2 » Hello, I'm a NEWBIE - HELP!! (Newbies assistance, User Guides and thank you notes)
Started by Pseudothink Creative Uses of CHDK
Started by bitterlake Script Writing
