Mathematica 9 is now available
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

RE: Re: Best practice for naming of options

  • To: mathgroup at smc.vnet.net
  • Subject: [mg71551] RE: [mg71522] Re: Best practice for naming of options
  • From: "Virgilio, Vincent - SSD" <Vincent.Virgilio at itt.com>
  • Date: Wed, 22 Nov 2006 05:22:31 -0500 (EST)

Andrew,

I have also wondered about best practices here. I decided to use full
context names when there were shadows or other chance of conflict.

Once, this forced me to think some about name lookup in Mathematica. I
wondered if future versions of Mathematica could expand their
name-lookup abilities along the lines of . . . C++. Here is a brief
tutorial on C++ name lookup:

http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,17
01,990,00.html

If this were applied to Mathematica, perhaps expression heads could
imply the scope of their contexts.  Then those contexts would have
name-lookup priority during evaluation of subexpressions (of the
expression head). Could this solve the option-name problem? Full context
names would still resolve shadows, but I think would be required much
less frequently (for those of us who use them).

Such additions could become breaking or silent changes to the
Mathematica language. They could also lead to surprising behavior. I
can't say either way---it would require an expert's judgement, and some
field trials.

Vince Virgilio


-----Original Message-----
From: Philipp [mailto:Philipp.M.O at gmail.com] 
Sent: Tuesday, November 21, 2006 7:05 AM
To: mathgroup at smc.vnet.net
Subject: [mg71551] [mg71522] Re: Best practice for naming of options

David,

I think you're missing the point a bit.

MySpaceScaleFunction type symbol names for options are fine until (as
Andrew points out) someone writes a package with a symbol that has
exactly the same name (hey, you came with it, so could anyone else).
Making the name longer only decreases the probability of conflict, it
does not remove it.

Andrew is asking for a methodology to avoid conflicts between "packaged"
symbols.

I don't have an answer, the only heuristic I can offer is "When in
doubt, use full context names for symbols".

Cheers
Philipp

David Park wrote:
> Andrew,
>
> What is wrong with using a name like MySpaceScaleFunction, or assuming

> that the option is actually associated with some function Foo,
FooScaleFunction?
> You say that it produces cumbersome option names but if you have a 
> usage message for it one can then use command completion Ctrl-K to 
> bring up the options or routines that start with Foo say. So it is not

> all that cumbersome, and having longer specific names vastly cuts down

> on the possibility of conflicts. In my opinion, longer specific names 
> are much better than short ambiguous names.
>
> David Park
> djmp at earthlink.net
> http://home.earthlink.net/~djmp/
>
> From: Andrew Moylan [mailto:andrew.j.moylan at gmail.com]
>
> 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?

************************************
This e-mail and any files transmitted with it are proprietary and intended solely
for the use of the individual or entity to whom they are addressed. If you have
received this e-mail in error please notify the sender. Please note that any views
or opinions presented in this e-mail are solely those of the author and do not
necessarily represent those of ITT, Inc. The recipient should check
this e-mail and any attachments for the presence of viruses. ITT accepts
no liability for any damage caused by any virus transmitted by this e-mail.
************************************



  • Prev by Date: Re: Method option to Solve
  • Next by Date: RE: Re: Best practice for naming of options
  • Previous by thread: Re: Re: Best practice for naming of options
  • Next by thread: RE: Re: Best practice for naming of options