Re: Update on Eliminating Singleton Objects

[John W. Eaton]

On 01/07/2018 08:28 PM, Rik wrote:

> This is a lot of code re-factoring.  Are there other benefits besides being
> able to run multiple interpreters out of the same program (which sounds
> like an edge use case)?  Is there an impact on performance if every
> function call has to push a pointer to the current interpreter on to the
> stack before executing?

These are good questions.

I think it makes the interpreter easier to understand if the objects 
that it is composed of are members of the interpreter object itself 
rather than just a bunch of other global objects, which was the case 
when pretty much everything was a singleton object or just some other 
global thing like the lexer and parser.  I think it will also help with 
memory issues if, as much as possible, we manage all resources in 
constructors/destructors.  Moving away from the singleton pattern should 
help do that for the interpreter itself.

If there are performance issues, then I think we can fix them by 
allowing more direct access to the interpreter object and its components 
where it is necessary.  But unless there really is a performance issue, 
I'd prefer to use member functions or pass a reference to the 
interpreter object.  I think eliminating globals makes the code easier 
to understand and modify, but maybe it is not so critical if the only 
real global object is the interpreter itself.

I know, it was my fault for introducing the singleton pattern in Octave. 
 But Jordi finally convinced me that it wasn't the best idea...  Where 
possible, I want to convert these global objects to be data members of 
some other object.  Typically that means making them part of the 
interpreter object.  But if they need to remain global, that's OK, but I 
want their lifetimes to be clear and predictible.

Anyway, I'm open to discussion.  If these goals are wrong or misguided, 
then let me know.

jwe