Re: options as a matter of course (any advice?)
- To: mathgroup at smc.vnet.net
- Subject: [mg69443] Re: options as a matter of course (any advice?)
- From: "Jens-Peer Kuska" <kuska at informatik.uni-leipzig.de>
- Date: Wed, 13 Sep 2006 04:00:53 -0400 (EDT)
- Organization: Uni Leipzig
- References: <firstname.lastname@example.org>
no, Show take the options and add/replace this
options in the
options of it's first argument. Thats why Show
has no options
but Graphics3D, Graphics, ... have options.
"Chris Chiasson" <chris at chiasson.name> schrieb im
Newsbeitrag news:ee3b7t$onv$1 at smc.vnet.net...
|I have begun to take notice of missing/undeclared
| results from the passing of options from a
function that doesn't use
| them or declare them to a function that does use
| Let me give a short example:
| Show takes and "uses" the Axes option, even
though it is not listed as
| an option for Show.
| This happens with other functions as well:
| StyleForm has no options but seems to accept
those of StyleBox
| Cell has many options but also accepts
Magnification, which is not on
| its list of options.
| This situation concerns me, because I am
starting to code things this
| way as well. I made a function that has an
option called Exports (note
| the s). The rhs of Exports is a list of option
lists. These options
| are passed to various functions, such as Export
(without the s). I
| need to add a useage message for Exports that
describes this and lists
| the various functions that see these options.
Otherwise, it will be
| hard for a user to know what will happen if she
or he changes, adds,
| or deletes an option from the nested list.
| I am curious as to what can be done to curtail
| because they lead to obfuscation of what code
Prev by Date:
Re: extract homogenous solution from DSolve?
Next by Date:
Previous by thread:
options as a matter of course (any advice?)
Next by thread:
Re: four argument form of infix