New debugging tools are all adding singletons

[StevenCostiou]

Every new debugging tool seems to need a dedicated registry to hold its model instances. This leads to writing a singleton each time, and we see many tools implementing its own singeton in class side. Exemple: object-centric, halt cache, debugger selector, etc.

Could we think of another way? a better design?

[estebanlm]

Can you elaborate a bit more?

[StevenCostiou]

Each time we add a debugging tool, there is a class with a singleton that holds objects. For example, the halt cache uses a registry of halts, the debugger selector keeps instances of DebugSession, the object-centric debugger keeps instances of object-centric breakpoints, etc.

Basically all the (debugging) tools need to keep instances of things somewhere and control them from there.

We are constantly adding singletons, with different namings (defaultInstance, default, singleton, etc.), then testing them (globally the same way).

Why not having a "Singleton service" that proposes an interface for "Singleton clients" that would be able to register their objects there?

[MarcusDenker]

Yes, one tiny step: There was the proposal to add a Stateful trait for Singletons.

• Konrad implemented it and changed all singletons, but it was rejected as a (undefined) part of that is not supposed to use Tratis
• I re-submitted the trait only so people can start to use it, but that was rejected as it had no users.

see https://github.com/pharo-project/pharo/pull/3204

[guillep]

I understood @StevenCostiou 's point as to avoid singletons, not making them just easier to use. Singletons are in general not a good solution as they prevent testing, isolating changes...