Re: Eliminating Singleton Objects

[John W. Eaton]

On 04/30/2017 11:28 PM, Rik wrote:

> Also, if the pointer to the interpreter really is used all over the code
> base, maybe it does make sense to have it be a global?  I know it is
> generally frowned upon, but it might actually be simpler then re-working
> the API to pass the pointer through to all functions.

I'm beginning to think the idea of being able to start multiple 
interpreters in a single program is just never going to be possible, at 
least not with the current libraries we use and APIs we need to support.

But even so, would it still be beneficial to more clearly define which 
objects own which data?  For example, the interpreter currently owns the 
evaluator and the load-path object.  It seems to me that most other 
global objects like the symbol table, type info, the call stack, etc., 
should probably also be part of the interpreter or evaluator rather than 
separate global singleton objects.

I guess the question I'm asking is whether we should have an "Octave 
interpreter" object that is composed of all the things that make up the 
interpreter, or whether we should have a bunch of global objects 
(implemented as singletons or not; that's really just an implementation 
detail) that are loosely organized to make up the interpreter.

One nice thing about having the objects that make up the interpreter 
organized as a single object is that all resource allocation for that 
interpreter object can be managed by the constructor and destructor for 
the object.  So, if things are done correctly, one may create/destroy 
interpreter objects as needed.  This could be useful for embedding the 
interpreter in applications.

Another advantage is that the components of the interpreter can be 
assumed to be valid as long as the interpreter object is valid.

Objects that are owned by the interpreter may (if needed) be constructed 
with a reference to the interpreter that contains them.  Then they can 
have access to other interpreter objects without having to use a global 
object.  To me, this seems similar to the idea of a parent widget in Qt.

I know this is not strictly necessary since we could always just use a 
global variable (and why not, if there is only ever going to be one 
interpreter object?).  But avoiding the global means we are at least 
moving in the direction of having a self-contained interpreter object 
that could allow for simultaneous instances.

Finally, here's what I'm thinking of for DEFUN-like built-in functions. 
I propose adding another signature for built-in functions that accepts a 
reference to the interpreter that invoked them.  For example

  DEFMETHOD (fun, interp, args, nargout)
  {
    // Here, interp is a reference, so
    // guaranteed to be valid.  Just use it.

    interp.do_something ();

    ...
  }

To me, this seems better than accessing a global pointer, or even 
passing a pointer, because a reference must be valid so there's no need 
to do something like

  if (! interp)
    error ("fun: no interpreter context!");

jwe