MathGroup Archive 2006

[Date Index] [Thread Index] [Author Index]

Search the Archive

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



  • Prev by Date: RE: Re: Best practice for naming of options
  • Next by Date: Re: Re: Arithmetic Puzzle (so simple it's hard)
  • Previous by thread: RE: Re: Best practice for naming of options
  • Next by thread: returning variable number of arguments from a Module[ ]