Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2006
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2006

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

Search the Archive

Best practice for naming of options

  • To: mathgroup at smc.vnet.net
  • Subject: [mg71473] Best practice for naming of options
  • From: "Andrew Moylan" <andrew.j.moylan at gmail.com>
  • Date: Mon, 20 Nov 2006 06:17:06 -0500 (EST)

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?


  • Prev by Date: Re: mathematica & fortran ??
  • Next by Date: Re: a (serious) question about character codes in Mathematica
  • Previous by thread: Re: Converting an expression to a list of terms?
  • Next by thread: RE: Best practice for naming of options