Re: Eliminating Singleton Objects

[Rik]

On 05/18/2017 01:40 PM, John W. Eaton wrote:
> 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.

In principle, it seems that even loosely related objects are probably
better off together.  On the other hand, I don't see the point in doing a
lot of proactive work on a topic that hasn't been figured out
definitively.  If the eventual resolution for enabling multiple
interpreters is going to require a different architecture then maybe we
should just leave the current code alone until that change is ready to be
made.  It seems that there are other topics, such as making cross-thread
data transfer reliable, that would be better uses of time.

>
> 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 ();
>
>     ...
>   }

How many lines of code needs to change to accommodate the new macro?  Since
the benefits are fairly nebulous at this point, I wouldn't want to change
the 871 DEFUN instances in libinterp.

--Rik