[Date Index] [Thread Index] [Author Index]
Best practice for naming of options
Hi all, When writing my own functions that use options, I sometimes have a problem where option names become shadowed by other packages that are loaded later. For example, I might want to use an option called ScaleFunction: BeginPackage["MySpace`"]; ScaleFunction::"usage" = "hello"; EndPackage; Needs["Graphics`"] Now the name ScaleFunction is shadowed by the option of the same name from the Graphics package: Evaluating ? ScaleFunction gives Graphics`Common`GraphicsCommon`ScaleFunction I can think of two possible solutions to this problem, each with a different problem: (1) I could try to always choose unique names for my options. This produces cumbersome option names and in any case only works until I or someone else writes a package with that option name. (2) I could use _strings_ for option names instead of symbols: Func["ScaleFunction" -> x] instead of Func[ScaleFunction -> x]. I have seen this done sometimes in the built-in Mathematica functions. Unfortunately, with this approach it no longer becomes possible to define usage text for options in the usual way: "ScaleFunction"::usage = "ScaleFunction is an option to Func that ..."; gives the warning Message::name : Message name ScaleFunction::usage is not of the form \ symbol::name or symbol::name::language. Is there a way to get the best of both worlds (define usage strings AND ensure that option names don't become shadowed)? Cheers, Andrew P.S. I observe that the built-in function NSum has an option called NSumTerms. I think this option would be better called Terms. Could it be that the writers of that function faced the same dilemma that I am facing?