RE: Re: Best practice for naming of options

*To*: mathgroup at smc.vnet.net*Subject*: [mg71545] RE: [mg71518] Re: Best practice for naming of options*From*: "David Park" <djmp at earthlink.net>*Date*: Wed, 22 Nov 2006 05:22:26 -0500 (EST)

Hi Andrew, Well, I think there is a method but it requires that you have your package name the Mathematica package that contains the conflicting name. Then you use a $NewMessage statement. For example, in my DrawGraphics`DrawingArrows` subpackage I add routines that modify the Arrow routine. I use... BeginPackage["DrawGraphics`DrawingArrows`", {"Graphics`Arrow`", "DrawGraphics`DrawingPaper`"}] and then write a usage message for Arrow as follows... $NewMessage[Arrow, "usage"] Arrow::usage = Arrow::usage <> "\nArrow[{start, finish}, opts...] is the same as Arrow[start, finish, \ opts]\nArrow[start, l, \[Theta], opts...] will draw an arrow from start at an \ angle \[Theta] to the x axis and of length l."; Then when a user types ?Arrow he gets a usage message with the new usages appended. In your case, Method is in the System` context and so it is automatically available. You should be able to write the following usage statement in your package and then use Method as an option name in your routines. $NewMessage[Method, "usage"] Method::usage = Method::usage <> "\nMethod is also an option for the Moylan Foo routine." which then gives... ?Method Method is an option to Solve, related functions, and various numerical \ functions, which specifies what algorithm to use in evaluating the result. Method is also an option for the Moylan Foo routine. Then you should be able to use Method as an option name in your package routines. David Park djmp at earthlink.net http://home.earthlink.net/~djmp/ From: Andrew Moylan [mailto:andrew.j.moylan at gmail.com] Hi David, Thanks for your reply. I agree that using a name like MySpaceScaleFunction appears to be the best possible solution. As for what is wrong with it: it's that it appears to be inconsistent with the option naming conventions employed throughout Mathematica. For example, in Mathematica we have the option Method, and we don't have the options NIntegrateMethod or NLimitMethod, even though the values that may be used for the Method option are completely different in the cases of NIntegrate and NLimit. In both cases "Method" is the best possible name. In constrast, I think it is unfortunate that, whereas the functions NLimit, ND, and EulerSum all expose an option called Terms (a clear, unambiguous, intuitive name), the function NSum instead exposes an option called NSumTerms. What do you think? Regards, Andrew