Re: DEFVARs in .oct files

[Paul Kienzle]

I believe I have made several suggestions over the years,  none of
them completely capturing good behaviour.

Today I would lean toward reducing the number of symbols in the
global namespace, either by putting the flags in a structure or
by defining something like a set function to set/restore them.
The structure syntax is cleaner than a function call with quotes
around each name.

Having a system which allows you to remove flags without changing
user code would be useful.  If the user queries a non-existent flag,
return [].  If the user sets a non-existent flag, then ignore it.
Allow packages to add their own flags, presumably in a package
namespace so that conflicting names are not a problem.

E.g.,

        env.misc.editor='vi';
    env.misc.default_license='GPL';
    env.gnuplot.replot = 1;

One question is whether you want the flag to affect only the
current context, or if it should also change the global context.
There used to be a lot of the former (e.g., empty_list_elements_ok)
which meant that well behaved functions needed unwind_protect
for a number of flags.  Fortunately most of these are gone now, so
I'm no longer asking for a system to restrict the change to the
current context.

- Paul

On Feb 10, 2006, at 1:52 PM, John W. Eaton wrote:

> On 10-Feb-2006, David Bateman wrote:
>
> | I have the tendency to place nothing in my .octaverc file and rely on
> | the defaults being sensible, so I'm less affected by this issue.
> |
> | If the idea was one or the other of the above solutions, I'd tend to 
> say
> | that the autoload idea was better, as then the control of the 
> variables
> | and their existence is in the hands of the maintainers of octave, and
> | the user doesn't need to do anything. There might be some issue if 
> the
> | user tries to overload one of these autoloaded variables with a 
> function
> | though..
>
> OK, I looked at this for a while, and I think we could do it, but it
> mean additional complication in the symbol table code (in both
> symtab.cc and variables.cc).  There is already a lot of potential for
> confusion there.
>
> Perhaps what we should do is what Paul Kienzle suggested some years
> ago.  Instead of built-in variables, we could have functions to do the
> same task.  Since functions can be autoloaded, there is no problem
> finding them in .oct files.  Functions may also be called without
> argument lists (or even empty an empty set of parens) so if we replace
> all current built-in variables with functions, references to those
> variables will still work in value contexts.  We would only have to
> make changes to code that assigns values to the built-in variables.
> If we adopt the convention that passing a value to these functions
> sets a new value for the built-in variable, we would only have to
> change things like
>
>   automatic_replot = 0;
>
> to be
>
>   automatic_replot (0);
>
> instead.
>
> This technique is of course not limited to .oct files, but can be
> implemented in .m files too, so there is another advantage.  Yes, you
> can also do it this way in .m files now, but you are then inconsistent
> with the way the built-in variables work.  It seems better to me to be
> able to have a consistent way of handling these kinds of things.
>
> Also, adding a new "autoload for built-in variables" thing or a
> "require" function is just one more potential gotcha for the future
> when/if a similar feature is added to the competition.
>
> So, after only N years, I'm coming around to the idea that Paul was
> right about this all along.
>
> Does anyone object ot making this change?  Will it cause too much pain
> and suffering to just do it, or should we think of some nicer
> migration path that will give people warnings about the change?  If we
> just make the change, then existing code that sets built-in variables
> using assignment statements will continue to work, at least in the
> sense that a statement like "automatic_replot = 0" won't fail at the
> time of the assignment, but it won't have any useful effect either.
> Instead of setting the built-in variable, it will just define a local
> variable with the name "automatic_replot".
>
> Comments?
>
> jwe