core is a singleton

[eagmon]

This introduces a global singleton instance core within the process_bigraph module. The core is implemented as a singleton of the ProcessTypes class, ensuring that only one instance of ProcessTypes exists. The ProcessTypes class was modified to follow the Singleton design pattern using the __new__ method to ensure only one instance is created

[prismofeverything]

This change successfully ensures that only a single instance of core exists in memory - however I don't think a singleton instance is appropriate for TypeSystem's role in the program. I can imagine use cases where we would want to be able to compute two different simulations in the same program which themselves have incompatible types registered in their respective core instances (a server that can run user-provided composites and display their results, for instance). Indeed, part of the goal of the system is to make the type system itself a state that can be computed by the system - this kind of self-reflection is only possible if new instances of the type definitions can be created and provided as context for further computations. This requirement alone requires the core instances be passed into whatever needs to access them.

I propose we continue with our dependency injection approach: most of the methods of core are called internally, and the user should in general only need to create one instance at initialization time and pass it into the outer composite.

[eagmon]

They also need to pass the core into each process. Each process when created also needs to declare a core in the init, passed into super. When making tests we need to create a fixture for core. There is a whole game with how to register types in core within a repository and then pass that one into the composite. I would say over 50% of the time we are debugging we ourselves have found it is core-related. I would do a count of the number of times core is used in each repo, I am certain it is over 100 times. I have seen separate TypeSystem cores and ProcessType cores, which has also led to bugs. This has been mostly just us coming upon these issues, not even the general public. When I am trying to onboard people, this becomes a thing every time.

Is all of this worth supporting a possible future hypothetical scenario with multiple incompatible type systems? It is actually hard to imagine this future scenario as being useful at all, I personally can't even think of an example in which we would use this -- can't we just have two projects if we want incompatible systems? Are they incompatible because of their methods conflicting with each other (hard to imagine what would make them incompatible). To me it doesn't seem this complex future hypothetical is worth all the issues mentioned in the paragraph above. I'm mostly trying to lower people's activation energy to understanding this repo and using it. Core is a major hurdle, and I don't think they should even have to know about it honestly for 100% of scenarios that we have ever discussed.