[Qt-creator] Object pool is gone?

[Eike Ziller]

> On 29. Apr 2019, at 05:24, Christian Gagneraud <chgans at gmail.com> wrote:
> 
> Hi there,

Hi,

> 
> I just noticed that the object pool is gone, QtC seems to use
> singletong all around the place now.

The pool is still there, but we restrict its use to when it solves a problem ;)

> Could someone share the rational behind getting rid of the object pool
> and replace it with "almost-under-control" singletons.

For the case “code actually wants to access a singleton instance of class XYZ to directly call methods on it (i.e. the code access to the header and has a hard library link dependency anyhow)” there is no semantic difference between calling
"PluginManager::getObject<XYZ>()” and calling "XYZ::instance()”
or between calling
“PluginManager::getObject<XYZ>()->someMethod()” and calling “XYZ::someMethod()”.
In this case the object pool does not solve a problem and is an unneeded indirection.

Also, its implementation does a linear search through all objects in the pool to find the correct instance, trying to qobject_cast everything until it finds an object where that succeeds. That is not very efficient, and making it more efficient is not trivial (it needs to take inheritance into account) - something we didn’t want to spend resources on.

The object pool is still there, for solving the issue of loose coupling / optional dependencies.

> Just an example, the `FileIconProviderImplementation *instance()`.
> Isn't it bad that the first one who calls one of the FileIconProvider
> namespaced function will control it's creation time?

When the actual singleton instance is created is now decided by whoever implemented the singleton class.
The implementor of the singleton class can still decide to create the instance at a specific point of time (e.g. done for ModeManager, which has a defined creation time during Core plugin initialization in the MainWindow constructor).
But lazy initialization is an option now too. This can be good (allocate resources only at a time when needed), or bad (no control over when the time needed for creation is spent).

> OK, this example is bad as the FileIconProvider doesn't depends on
> anything else.
> How do you deal with the risk of inter-dependencies and initialisation
> order (and loops, ...)?

See above, there is choice now.

> I really would love to hear about the design decision, from a
> technical point of view.
> 
> Chris
> _______________________________________________
> Qt-creator mailing list
> Qt-creator at qt-project.org
> https://lists.qt-project.org/listinfo/qt-creator

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.ziller at qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B