Eliminating Singleton Objects

[John W. Eaton]

In this changeset,

  http://hg.savannah.gnu.org/hgweb/octave/rev/d24d01273bd0

I eliminated the load_path singleton object with a global load_path 
object (actually owned by the interpreter class, but with global access 
allowed).

In Octave, singleton objects are typically (always?) used to manage 
global data, so providing global access is nothing new.  What is new is 
that the code is simpler if we don't use the singleton idiom because  we 
can eliminate many static functions that simply provide access to a 
global object.  The only advantage to having the singleton is that you 
don't have to worry about when initialization of the global object will 
happen; it occurs on the first use.  But then special treatment is also 
needed to clean up and delete the the global object managed by the 
singleton.  So I'd rather have these objects converted to normal 
classes, and if possible, converted from global to local objects.

For the load_path object, it makes sense to me that it is owned by the 
interpreter.  So that's where it is now initialized and it exists as 
long as the interpreter object exists.

We currently have ordinary functions outside of the interpreter that 
need access to the load_path (for example, any DEFUN like path, addpath, 
rmpath, etc. that accesses the load_path object).  These functions 
currently access the the global load_path object using the new function 
octave::__get_load_path__.  This function is not exported (the header 
that declares it is not installed) and I'd like to eliminate it.  To do 
that, we need a way to pass a pointer (or reference) to the interpreter 
to DEFUN functions.  I'm thinking about inserting a pointer to the 
interpreter into the argument list that is passed to DEFUN functions. 
Then functions like path could extract that info from the argument list 
and not have to access the load_path using a global variable.  This may 
involve a change to DEFUN so that it accepts something like 
defun_arg_list instead of octave_value_list.  But defun_arg_list would 
be convertible to octave_value_list, so existing functions should not 
have to change.

One question is what should happen to DEFUN functions called using 
feval?  We can provide an interpreter::feval method that can pass a 
pointer to the interpreter object, but the current feval function would 
not do that.  Is this a problem for existing user code (anything inside 
Octave can easily be changed, so I'm not worried about what changes are 
required there).

If this problem can be solved for load_path, then there are a number of 
other singleton objects that we can eliminate, also without needing to 
provide global access to them.

jwe