Re: Eliminating Singleton Objects

[Rik]

On 04/25/2017 01:11 PM, address@hidden wrote:

Subject:

Eliminating Singleton Objects

From:

"John W. Eaton" <address@hidden>

Date:

04/25/2017 12:43 PM

To:

Octave Maintainers List <address@hidden>

List-Post:

<mailto:address@hidden>

Content-Transfer-Encoding:

7bit

Precedence:

list

MIME-Version:

1.0

Message-ID:

<address@hidden>

Content-Type:

text/plain; charset=utf-8; format=flowed

Message:

5

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.

Is there a performance issue here?  If you start passing too many arguments to a function, more than can conveniently fit into the number of scratch registers that your CPU has, then you have to pass arguments on the stack which will slow things down.  But I can't quite tell if you are suggesting another parameter, or whether you want to include the pointer to the interpreter as say the first entry in the octave_value_list passed as inputs to the function.  Presumably the octave_value_list is already passed as a pointer/reference since it could be large.  In that case it wouldn't have an impact.

--Rik