Open rpatters1 opened 2 years ago
I don't, and that's what the client library is for: https://www.finalelua.com/docs/library/client
In reality, anytime in the future we use a feature only supported by new versions of RGP Lua (especially in the function library) we should be using client.supports
. So I don't see a huge downside to this. Even if Finale did support it, we should be using client.supports
because older versions of RGP Lua didn't support it.
Someone on the JW Lua list suggested throwing an error instead of omitting the functions. I like this idea, because it would work for C++ clients as well. I'm not sure if it will be possible. I will have to
throw
into the PDK Framework codebase.This might force a better discipline around the usage of these properties. Either specify a minimum Finale version or use pcall
.
I will soon be adding to RGP Lua some methods and properties that are not available before a certain Finale version. Previously when this has happened, the methods and properties appear in all Finale versions but return a default value in earlier Finale versions where they aren't supported. Until now there has always been an appropriate default value.
However, these new methods and properties I plan to add do not have useful default values in earlier Finale versions. In fact, it would be a bad idea to return anything at all unless running in an supported Finale version.
To me the best solution would appear to be not to hook up these methods and properties to Lua if the Finale version doesn't support them. But that means, in perpetuity, Lua programmers will have to check them for
nil
before calling them. Does anyone have other/better ideas?