Central Application class holding all current singletons

[franzlst]

A central application class (Application in the core, GUIApplication in the gui module) should be introduced, being the only existing singleton class. It will hold references to the configuration, state machine manger, etc.

Another aspect of this (which needs to be discussed) is that this allows the observable exchange of classes: The aim is to make changes of elements in the two singleton modules observable and especially the exchange observable. Finally this feature will offer the possibility to exchange and reconfigure rafcon elements using the observer-pattern without restarting.

Originally created by @Rbelder at 2016-05-17 13:18:46+00:00 (moved from RMC internal repository)

[franzlst]

Alternatively to an Application class, one could also make use of the "Borg pattern": http://code.activestate.com/recipes/66531-singleton-we-dont-need-no-stinkin-singleton-the-bo/

Originally created by @franzlst (Franz.Steinmetz@dlr.de) at 2017-02-06 09:09:01+00:00 (moved from RMC internal repository)

[franzlst]

The here so called "Borg pattern" we have had close to once in the beginning for the main window when I was not allowing a second generation of the MainWindowView and Controller. To give the name singleton some sense. The Borg class only seems to integrate implicit handing of the first generated object instate of not allowing and raising an error when trying to initialize a second object.

The general question is wanna we allow to substitute an object (class-X) by a class-Y object that inherit from class-X and which was declared in a lately import (after all plugin init-interface have run)???

I would generally say no.

This question is central because the initial creation of this issue grow from the perspective that we wanna allow multiple and later newly generation of so called singleton objects (so that those are only objects that are supposed to be the only object used of this kind (singleton)).

But do we have situations where it has any advantage that an exchange of a class-X object happens with a class-Y object??? Anyway monkey patching would still be possible at any time of execution (what again we should not do).

In the paste as I remember the hole idea came from (the crazy aim of) implicit handling the exchange of very different front end solutions by an observer pattern where every child element can observe all exchanges of parent objects and thereby decide to observe to new (parent) object.
I would talk about this or similar exchange of observed object or preserving of child objects without over and over generating new ones and decide from this point of view how we continue here. I think it is more productive if this kind of discussion don't happen here but in person. 😄

Originally created by @Rbelder at 2017-02-06 11:32:14+00:00 (moved from RMC internal repository)

[franzlst]

Sorry parent object is a bit wrong, core object and model, view or controller are more right. In relation of Controller the parent seems a bit right. ☝️

Originally created by @Rbelder at 2017-02-06 11:37:40+00:00 (moved from RMC internal repository)

[franzlst]

I think it is more productive if this kind of discussion don't happen here but in person. 😄

You started the discussion, I only wanted to add another (uncommented) view to this issue.

The here so called "Borg pattern" we have had close to once in the beginning for the main window when I was not allowing a second generation of the MainWindowView and Controller.

No, this has nothing to do with this pattern.

The Borg class only seems to integrate implicit handing of the first generated object instate of not allowing and raising an error when trying to initialize a second object.

No, you didn't get the idea of the pattern/implementation.

Assume we have a "Borg"-class: class Borg: [...]

This class is then instantiated several times:
b1 = Borg()
b2 = Borg()

Those two objects always share the same state, though the are not identical:

assert b1 is not b2
b1.a = 1
assert b1.a == b2.a
b2.a = 2
assert b1.a == b2.a
b3 = Borg()
assert b1.a == b3.a

This could e.g. be used for the configuration, which would no longer need a global instance. The configuration would be loaded initially. All further components that want to access the configuration just create a new instance of the configuration class and share the same state.

Originally created by @franzlst (Franz.Steinmetz@dlr.de) at 2017-02-06 11:46:30+00:00 (moved from RMC internal repository)

[franzlst]

I have read this so there is only one difference, that why I ask. And I know not everything I try to tell reach the address.

But you have to admit that it is completely doing the same (as handing the same object to all newly calls of __ini__) except that you maybe construct this assert b1 is not b2 what is necessary for what?

This state_dict seems not to be the big invention?!

Originally created by @Rbelder at 2017-02-06 12:03:47+00:00 (moved from RMC internal repository)

[franzlst]

The only advantage I can see is if your Borg classes are used often for different widgets and other classes are inherit from the base class. But still if this objects are in the mvc pattern I think you have to avoid observation of core elements in the base class. We should talk directly as I wrote above. 😃

Originally created by @Rbelder at 2017-02-06 12:10:27+00:00 (moved from RMC internal repository)

[franzlst]

When tackling this issue, have a look at the GtkApplication class together with GtkApplicationWindow. There is also a HowTo.

Originally created by @franzlst (Franz.Steinmetz@dlr.de) at 2018-10-10 09:43:57+00:00 (moved from RMC internal repository)