I'm not sure the topic of default values is worth the time I'm about to devote
to it.

Let's take an example to make this easier.  A program lets a user set a value
for "foo" of either "enable" or "disable".  The value is remembered between
runs of the program.  When the program is first installed, the value is set to
"disable", so that is the default.  When the program displays the value of foo,
if the value is "disable", the program will show it as "disable (default)" to
indicate that the parameter is set to its default value.

That is all very straightforward.  Now let's add an "enhancement" that lets the
user set the value of "foo" to "default", which essentially means "let the
program decide".  The program then must make a "best" decision on some basis.
When the program displays the value of foo, if the value is "default" the
program will show, for example, "default (enable)" to indicate its decision
that the best value for foo is "enable".

Some comments:

1.  The first scheme is simpler for the programmer and the user.

2.  The second scheme provides scope for the program to help the user make
better choices.  But the program could also achieve this just by advising the
user; for example the program could state: "Your application would run faster
if 'foo' were set to 'enable'".

3.  If the program changes the value of "foo" for some reason (new program
release, other parameter change, etc.) it might not actually be a better
value.  The user will be less likely to know the reason for the loss of
performance if the program has changed the value.

Comment 3 is my main objection to having a program set parameter values.

Jim



> Date:          Thu, 20 Aug 1998 17:18:30 -0500
> Reply-to:      Jeff Woods <[log in to unmask]>
> From:          Jeff Woods <[log in to unmask]>
> Subject:       Re: "SUB-DATABASES"
> To:            [log in to unmask]

> At 11:42 AM 8-20-98 -0800, Jim Kramer wrote:
> >I'm not so sure it's a good idea to change the meaning of defaults from one
> >release to another.
>
> OK, then instead of having "default" and making it the default, call it
> "automatic" and leave either "enabled" or "disabled" the default as they
> are now.
>
> But personally I prefer Gavin's only slightly less paranoid implementation
> of having explicitly "default" values which might change when deemed
> appropriate.
>
> Also, there may be other places outside Image where such functionality
> might be used in future developments.
> --
> Jeff Woods
> [log in to unmask] [PGP key available here via finger]
>

Jim Kramer /Lund Performance Solutions
Director of Research and Development
phone: (541) 926-3800  fax:   (541) 926-7723
email: [log in to unmask]    home:  [log in to unmask]
http://www.lund.com